Translation Support

[bisby]

Describe the feature you'd like When building out local UI strings, build them in a way that supports translations.

Additional context

[cewert]

Looks like we'd need to use the Tr() function https://developer.roku.com/docs/references/brightscript/language/global-utility-functions.md#trsource-as-string-as-string

[neilsb]

There a couple of features of the Roku localisation implementation that are probably worth thinking about.

According to the docs, strings within <children> or <interface> blocks within the xml file will automatically be translated. Within the .brs code you would call the tr() function to have a string translated. In both cases, if a translation does not exist for the users current locale, the the original string is used.

One thing to consider is what we use for the source string for the translation. There are basically 2 options - we can use the English version of the text (e.g. "favorite"), or some key (e.g. "SET_FAVOURITE"). If we the English text is used then it means that if the string has not been translated into a particular local then the English word is used. If a key is used, then that is displayed in the UI until it is translated. I suspect given those 2 results, displaying the English version rather than the key is preferable.

However, the first issue with using the English text as the key is that the same word may translate differently given the context. i.e. if favorite is being used as an noun (i.e. This movie has been marked as a favorite) or a verb (i.e. Click this button to favorite this movie). In this case if the text is set in the XML then both of the meanings would be translated to the same word. In this scenario it would probably be preferable to use a key which could give context. "Roku best practices therefore strongly recommend initializing RSG field values that need to be localized in the corresponding BrightScript Init() function"

Another advantage of using a key would be when the English wording is changed. Either all the translation files would need to be updated to also update the source key, or there would be a translation in the English locale file translating from the original English to a reworded English phrase, which just seems messy.

Given all of the above, one option would be that we use some form of key for the string to be translated, always set it from the .brs file, and write our own translate function to use (as opposed to the tr() function) which will return the English string if a string does not exist in the users locale.

Thoughts?

[1hitsong]

@neilsb @jimdogx We good to close this issue?

[jimdogx]

@neilsb @jimdogx We good to close this issue?

I believe Neil is still interested in a better approach to translations. However this issue in particular, "Translation Support" I believe can be closed. It may not be the best solution, but we do have "a solution" currently in play.

[neilsb]

Potentially worth moving to (or creating) a translation discussion point to go into this in more detail.

There are certainly Jellyfin Roku users whose native language is not in the very limited list that Roku support, so rolling out own translation would be worth discussing, as well as considering the options/limitations mentioned in the previous comment.

But yes, an issue is probably not the best place for this, so happy to close this one for now since we are ensuring all PRs include translation.

[1hitsong]

Yeah, let's move to a discussion and take it from there. I believe this core issue as originally posted is satisfied.