GUI translation bundles

GUI translation bundles

[susan jasinski]

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?

Thank you, Susan Jasinski

Re: GUI translation bundles

[Alexander Amelkin]

[-- Attachment #1.1: Type: text/plain, Size: 2955 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: GUI translation bundles

[Derick]

[-- Attachment #1: Type: text/plain, Size: 4974 bytes --]

Hi Alexander!

Are you going to use some ready framework for translations or are you going
> to develop a new one?


After some previous discussions, it was decided to use Angular Translate -
https://github.com/angular-translate/angular-translate



> It would be great if the solution provided an option for quick language
> switching.


The suggested pattern would be a simple language switcher on the login page.

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.


This is a great point! I would expect, in the example you provided, for the
property value to be the complete sentence, e.g. { new_messages: "You have
{variable} new messages" }.

Derick Montague
* * * * * * * * * * * * * * * *
Mobile: 512-609-0760
http://www.derick-montague.me


On Mon, Feb 18, 2019 at 3:19 AM Alexander Amelkin <a.amelkin@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
>
>
>

[-- Attachment #2: Type: text/html, Size: 6583 bytes --]

Re: 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@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
>
>