GUI translation bundles

[susan jasinski]

Thank you for your feedback, Alexander.

- Angular Translate framework will be used for our GUI globalization service

- There will be a language selector on the login panel. It will be
enabled when after we have more than one translation completed/tested.

- You are right ... adding variables into the middle of a text string
is challenging for translators. We found 2 instances of this in the
current GUI build and changed the phrase so that the variable is at
the end of the phr. For example, on the Overview panel, we changed
"Turn on/off server LED" to "Turn server LED on/off".

- Regarding common phrases, I meant those phrases or words that appear
on many or most panels. For example, "Cancel" and "Save settings" are
2 buttons that will appear on several of the new panels IBM is working
on. In this case, should we include them in the bundle for every page
(if that is the route we choose), or should we add them to this
over-arching bundle so they are only translated one time, therefore
ensuring translation consistency?


On Mon, Feb 18, 2019 at 3:19 AM Alexander Amelkin <a.amelkin at yadro.com> wrote:
>
> Hi, Susan!
>
> 15.02.2019 23:17, susan jasinski wrote:
>
> > I’d like some feedback about how to breakdown translation bundles for the GUI.
> >
> > My initial thought is to create a bundle per panel since companies
> > have the option to pick and choose which upstream panels they want to
> > use. Would this be an overwhelming amount of bundles? Does this idea
> > scale well as we grow the number of panels? Does this scale well as
> > new panels are added after existing panels have already been
> > translated?
> >
> > In addition, there could a “global” bundle for navigation and header,
> > Should this include words/phrases that are common across many panels
> > such as “save” and “cancel”?
> >
> > Also, should GUI notifications/messages be in their own bundle or put
> > into their respective panel’s bundle?
> >
> > Can you think of other factors that should guide this decision?
>
> Are you going to use some ready framework for translations or are you going to develop a new one?
>
> It would be great if the solution provided an option for quick language switching.
>
> I once implemented such a solution, it used a json map of English strings to local strings. All translatable objects had a special class name, and the client-side Javascript code used that class to find all to-be-translated objects and on the fly changed their innerHTML using the map (saving the original content in an object's property). The con was that the implementation was only able to process simple strings and couldn't be applied to objects containing variable text (e.g. values embedded in text like "You have 12 new messages"). The problem is that different languages may require the variable part at different locations within the string and also may use inclinations, so you can't just break such strings apart and translate "You have" and "new messages" separately because the translation may not just require writing it like "12 new messages you have", but will also be different for, say, 21 and 22 messages. At least for Russian language the latter is definitely a problem
> to think of: we'll say "У вас 21 новОЕ сообщениЕ", but "У вас 22 новЫХ сообщениЯ". I believe other Slavic languages, and at least German and French are also affected by similar problems.
>
> That also concerns your question about "common" phrases. What is "common" in English, may differ significantly depending on context in other languages.
>
> I implore you to not forget about such peculiarities. In the past I've had issues with some software packages whose authors didn't think about that, and it was a pain translating those packages.
>
> As to bundling, I think that if something is shipped as a separate bundle, can be removed or added, then the translation data must go along with the rest of the bundle. The translation engine however must either be a separate bundle per se or be embedded into the core of WebUI.
>
> Alexander Amelkin
>
>