All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Amelkin <a.amelkin@yadro.com>
To: <openbmc@lists.ozlabs.org>
Subject: Re: GUI translation bundles
Date: Mon, 18 Feb 2019 12:19:19 +0300	[thread overview]
Message-ID: <c28330a3-e3ab-56c8-b9bb-1a4160a08466@yadro.com> (raw)
In-Reply-To: <CANT4Nr+Gpd7roWyPT5vpeskL9bvKBbsKKma_6WhPpenWdwACwg@mail.gmail.com>


[-- 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 --]

  reply	other threads:[~2019-02-18  9:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-15 20:17 GUI translation bundles susan jasinski
2019-02-18  9:19 ` Alexander Amelkin [this message]
2019-02-19 19:02   ` Derick
2019-02-21 17:49   ` susan jasinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c28330a3-e3ab-56c8-b9bb-1a4160a08466@yadro.com \
    --to=a.amelkin@yadro.com \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.