Creating multi-lingual help center/portal with unsupported languages 🤔

[Tomislav Tobijas]

Hi everyone,

I was wondering if anyone had any experience with designing a help center/portal(s) with translations to unsupported languages.

Usually, we only had to construct portals that are used by the same nation (e.g. Croatian), but more recently we're starting to expand those projects to support more nations, mostly within Eastern Europe.

In this specific case, we're talking about language translations (only the customer-facing side) for the following countries:

• Croatia
• Slovenia
• Serbia
• Bulgaria
• Romania (supported)

I know there are open suggestions such as I18N-3834: Add more European languages but I was just wondering what workarounds have you used to achieve something like this.

Have you created different service projects for each country or is there something else?
I guess, potentially, you could use request type restrictions and then create multiple request types for the same thing, where each one would have its language.

Note that I would like to do this natively without using Marketplace solutions.

Cheers,
Tobi

[Tomislav Tobijas]

One new information/note regarding internationalization for European countries.

Atlassian has recently rolled out support for Croatian, Serbian, Slovenian and Ukrainian (only for Help center and Customer Portal). More info here: https://support.atlassian.com/atlassian-account/docs/manage-your-language-preferences/

[Valeria di Domenico]

Hello @Tomislav Tobijas ,

Thank you for your answer. I wanted to confirm that you’re right — the Knowledge Base must be created separately in each language. However, we are still unsure whether the contact form for incoming customers also needs to be created separately. It seems that the browser’s automatic translation only translates parts of the contact form. Do you agree?

Could you also confirm whether the only way for customers to filter articles is by labeling each article with keywords — and that these keywords must be created and assigned by the administrator? Or is it possible to select labels independently, based on how the filtering system works with the web algorithm?

I hope my explanation is clear.

Wishing you a nice day, and let’s keep in touch to share more insights about JIRA.

[Tomislav Tobijas]

However, we are still unsure whether the contact form for incoming customers also needs to be created separately. It seems that the browser’s automatic translation only translates parts of the contact form. Do you agree?

Yeah, that's probably true. Can you just clarify which parts of the form are not translated? We could then check if this is 'resolvable' 👀

Could you also confirm whether the only way for customers to filter articles is by labeling each article with keywords — and that these keywords must be created and assigned by the administrator? Or is it possible to select labels independently, based on how the filtering system works with the web algorithm?

As for this, it depends. If we are talking about customer search, in the help center—those users cannot filter by anything other by keywords or phrases, which are then searched through KB titles and content. Basically, they cannot filter by labels.

Labels are primarily used when talking about 'connecting' JSM requests with specific articles that contain defined labels. More on that here: Set up article suggestions in request forms 

The distinction between customers and agents is needed here to see which filtering we're talking about.

[Valeria di Domenico]

Hi, sorry for replying only now. Of course, it’s a bit difficult to explain what I mean in writing. 

So I’ll explain step by step.

I’m an agent, and I’m creating a contact form for clients who need support with anything related to the services offered by the German company I work for.

Client K (a random person who wants to receive services from the company, which I’ll call M) tries to get in touch with us. They click on “Kontakt” and are already presented with the option to choose a form in English or in German.

This is because we’ve found that browser-based automatic translation only translates some elements and is not accurate.

Even though we’ve created two separate forms, here’s what happens when the client has to choose between English and German: the subcategory descriptions in the English version are still being translated into German if the browser isn’t set to English.

This happens even though we don’t want it to. For example, the client selects the English form, but their browser language is still German – the categories we specifically created in English are translated in German.

The reason why it was necessary to create a separate English contact form is because the automatic browser translation from German to English is unreliable, and articles that contain links and screenshots – even if the articles are automatically translated by the browser – of course point to content in another language. The screenshots remain in German, and the links lead to German resources, which makes it confusing for English-speaking users.
For this reason, it seems necessary to create a separate English Knowledge Base as well.

As for this, it depends. If we are talking about customer search, in the help center—those users cannot filter by anything other by keywords or phrases, which are then searched through KB titles and content. Basically, they cannot filter by labels.That actually reinforces the need for having two separate Knowledge Bases in German and English.

Since customers can only search using keywords or phrases—and not filter by labels or categories—this creates a problem: if a client searches for an English keyword (e.g., “ticket”), and that same word also appears in German articles, the search results will include articles in both languages.

This means the client will be forced to browse through content in a language they don’t speak or aren’t interested in.

The core issue is that there’s currently no way to restrict search results to language-specific content or to link a specific Knowledge Base to a specific Kontakt form in a specific language. Even if we create separate forms, we can’t guarantee that the articles suggested will be only in the appropriate language.

So, if Client K speaks English and selects the English contact form, they must first make sure their browser is set to English, or the form might still be automatically translated. Then, when they try to search for help articles, they’ll have to deal with mixed-language results—without the ability to filter out irrelevant ones.

That’s why creating and maintaining separate, language-specific Knowledge Bases (and ideally linking them clearly to the respective forms) is so important in our case.

I hope my explanation was clear enough. Thank you for your support.

Regards,

Valeria

[Valeria di Domenico]

Hi Tobijas,

I am expierincing the same Issue. We want to offer Knowledge Base Articles at least in German and englisch and we still did't understand how we can do it without translating manually every single article. Otherweise how we set the Knoledgebase to be visible just for the selected languange? Coul someone direct me to links or solutions? Thanks a lot

[Tomislav Tobijas]

Hi @Valeria di Domenico ,

This seems to have gone under my radar. 👀

From my knowledge, customers usually maintain separate KBs for each language. With AI tools such as Rovo, I guess this can be much quicker than it used to be.
Related to translations in Confluence, I'm now sure how that's generally done, as we mostly write either in English or in Croatian.

And as for KBs being visible only to selected languages, I'd say you would need to have a similar thing—construct multiple KBs and multiple portals (one for each language) and then connect each language KB with the appropriate JSM portal 🤔