Internationalization approach for Forge Apps?

Does Atlassian suggest an internationalization approach?
(Maybe depending on using UI Kit / Custom UI)

I couldn’t find any hint therefor.

2 Likes

I would prefer not to have a suggestion on how to do internationalization if using Custom UI. An approach similar to AJS.Meta would be fine, i.e., providing some context information such that the Custom UI can choose the language correctly. Then your app can make use of e.g. i18next, react-intl, js-lingui… or whatever you want or are already using.

3 Likes

I am using the myself rest endpoint call once my Custom UI initially loads. Then I transfer the locale and timezone into my own React Context so that I have it ready everywhere. Then I can use i18next or custom i18n tools.

const response = await this.api.asUser().requestJira(`/rest/api/3/myself`, DEFAULT_JSON_HEADERS);
//  timeZone: string | undefined;
//  locale: string | undefined;

If it is undefined, I fallback to en_US and some hard coded timezone or UTC.

Maybe Atlassian can suggest a better approach :slight_smile:

6 Likes

Sounds like a valid approach. My only concern is the user experience and number of requests. Imagine that every vendor on every app load calls this endpoint. You would see a lot of requests just to get some static information. As for the user experience: What happens if the request fails? If you fallback to e.g. en_US then this might not be an ideal user experience, especially if the user was working with the same app in a different language before, e.g. de_DE.

I mean it is serverless :smiley: Atlassian should be able to easily cache these types of requests that have no parameters. Let’s hear what the Atlassian staff has to say :slight_smile:

Hey All,

Thanks for this information. I’m going to have a chat with the team to unpack this further. :slight_smile:

2 Likes

Hey @danielwinterw,
is there anything new we can expect?

Hey @FranzBinder,

I’m still discussing this internally. I will let you know if there are any updates :slight_smile:

Hey @danielwinterw,
you all were probably busy with prepaparing the last updates / announcements. :+1:
May be this are still beginners questions … - I’m still curious if you have any news for me!

In the meantime I tried a few things in my Confluence dummy app. This may be also input for you.
I appreciate your adivce. Thanks in advance!

Get the current locale

As @clouless suggested:
Using const response = await api .asUser() .requestJira("/rest/api/3/mypreferences/locale", ... works fine.

My concerns:

  • A Jira call inside a Confluence Forge app requires additional permissions in manifest.yml (manage:jira-configuration) and forge install for Jira as well
  • Nevertheless I was asked for allowing permission during runtime.

Am I doing something wrong? But this doesn’t seem straigthforward for me.

Test with LinguiJS ( https://lingui.js.org/ )
I tried to use this approach due to the small footprint - which should be the same interest for Atlassian.

My first impressions:

  • import { I18nProvider } from "@lingui/react"; let to a forge deploy error: “… react missing in node module @lingui/react/cjs

  • So I installed : npm i --peerdeps react@^15.0.0
    => no more deploy errors.

  • The code

return (
<Fragment>
  <I18nProvider language="en">
    <Text>
      {config.name} is {config.age} years old. Language is {locale}
    </Text>
  </I18nProvider>
</Fragment>

let to runtimee error “Cannot call a class as a function …:open_mouth:
The reason is the new component <I18nProvider>

You cannot use React on the serverside together with Forge UI.
You will need to write your own logic for Forge UI.
I18nNext can only be used with React in Custom UI together with React.

2 Likes

Hey @danielwinterw,

I don’t want to bother anyone but I’m really eager to get an answer - especially for UI KIT for Confluence macros it would be good to know: how to detect the current locale in a simple way (for the end-user)!
Am I the only one who doesn’t know this?

Thanks in advance!

3 Likes

There are a few problems here:

  • There should be a way to localize entries in manifest.yml file. Example: “title” and “label” attributes of an issue glance. These are only things displayed to the users until they click on “label”. If we can’t localize these, localizing other parts with Custom UI is not very helpful.
  • Ideally, locale/timezone should be part of context information so that we should not make a request to server for just to get them. Because we can’t render a single line of UI without knowing locale.
    I have search Forge Agile Board, and there seems to be any ticket related with internalization. Please correct me if I’m wrong.
5 Likes

Hey @FranzBinder, we are aware of the need for internationalisation features, however these are not scheduled to be completed until early next year. In the meantime, requests to external locale and timezone APIs should become a lot faster as we are currently working on adding Oauth request capabilities to Custom UI in order to prevent the need to proxy requests via the FaaS. Hopefully this can be useful as a workaround for you.

1 Like

Thanks @JordanKoukides for your reply.
Maybe I’m wrong but I can’t see any workaround which at least helps me to detect the locale. (the Jira API works but leads to a strange “allow”-procedure for the end user).
Better: [FRGE-266] Pass user timezone and locale in UI Kit context - Ecosystem Jira

1 Like

No worries @FranzBinder.
Due to increased emphasis we have placed on control and transparency over user’s personal data in Forge, this ‘allow-procedure’ is standard when any external API is called. The ticket you have linked is the work we have roadmapped to build ‘native internationalisation’ into Forge, but as I mentioned we don’t foresee this being completed until early next year at the moment. We do review these projects on a quarterly basis so this could be sooner if we see more asks for it from the community.