Hello!
I'm currenly reworking the French translation, and I noticed several little annoyances:
First, some strings not present in the POT template. Are the "translated" message missing in the source? I provide below the incriminated string, as displayed in English (with the correct case).
- "fix layout" in the halo menu for the script editors, - "Script Editor" - "Forward direction (hold down shift key and drag to change it)" on any green arrow, - "Etoys Activity" in the Sugar navigator - "PaintBox" - "GStreamerPlayer" - "A ChessMove" - "translucent" and "no color" in the color chooser panels.
I'll very probably discover other ones later on.
Then, I've some trouble with certain strings, used both in the viewer categories and in another place. For instance, the string "restore base graphic" is present in the viewer category Graphics and in the object context menu. I would like to translate it differently in both case (for instance, capitalization and infinitive in the menu (->"Rétablir l'apparence initiale"), and third person of simple present in the viewer ("Sketch. reprend l'apparence initiale"). Another annoying case: top, bottom, left, right. When I want my user to choose a position for a flap for instance, I need to translated it "En haut / en bas / à gauche / à droite". In the category "Geometry", it's simply "haut, bas, gauche, droite".
Any suggestion to improve these localizations issues?
Greetings, Séverin
Hi Severin,
On Tue, 10 Feb 2009, Séverin Lemaignan wrote: [...]
Then, I've some trouble with certain strings, used both in the viewer categories and in another place. For instance, the string "restore base graphic" is present in the viewer category Graphics and in the object context menu. I would like to translate it differently in both case (for instance, capitalization and infinitive in the menu (->"Rétablir l'apparence initiale"), and third person of simple present in the viewer ("Sketch. reprend l'apparence initiale"). Another annoying case: top, bottom, left, right. When I want my user to choose a position for a flap for instance, I need to translated it "En haut / en bas / à gauche / à droite". In the category "Geometry", it's simply "haut, bas, gauche, droite".
This is a problem we encountered with the German translation as well. For example we'd like to translate strings differently in etoys-tiles and menu-entries. Actually this is a serious issue when using etoys at school.
There has been some discussion on this topic on the localization-list last year. A solution would be to provide some information about "context" of a string to be translated. This is a feature gettext and pootle are capable of. It also would help to make strings unique in pootle which would it make possible finally to use 'suggestions' on pootle, which doesn't work on pootle for etoys and scratch at the moment.
To make all this happen there's need for a discussion on what meaningful "context" might be.
From my point of view as a translator I'd suggest contexts like
'script-tile', 'menu-entry', 'balloon-help' as a rather simple concept. Another choice might be the message-selector, i.e something like 'class>>selector'.
Strings this is really an issue for are short ones (three words or less) like 'open' which in German can be translated as 'offen', 'öffnen', 'öffne', depending on context even as 'öffnet'.
Markus ----------------------------------------------- Markus Schlager m.slg@gmx.de
Hello Markus,
A solution would be to provide some information about "context" of a string to be translated. This is a feature gettext and pootle are capable
I fear that's not the only problem: some strings are unique in English (ie occur only once in the .pot template) but have different translations in other language. We need not only informations on the context (class>>selector info is already present in the .po) but as well a way to distinguish in the Squeak source between "top [menu-entry]", "top [script-tile]", "top [somewhere-else]", etc. And I'm not sure it can be easily solved (since it's the same in English, each of these "top" would always appear as 'top'.translated in the source and thus generate only one entry with Gettext. Or maybe Gettext has disambiguation mechanisms?).
Have a nice day, Séverin
On Wed, Feb 11, 2009 at 1:17 PM, Séverin Lemaignan skadge@gmail.com wrote:
Hello Markus,
A solution would be to provide some information about "context" of a string to be translated. This is a feature gettext and pootle are capable
I fear that's not the only problem: some strings are unique in English (ie occur only once in the .pot template) but have different translations in other language. We need not only informations on the context (class>>selector info is already present in the .po) but as well a way to distinguish in the Squeak source between "top [menu-entry]", "top [script-tile]", "top [somewhere-else]", etc. And I'm not sure it can be easily solved (since it's the same in English, each of these "top" would always appear as 'top'.translated in the source and thus generate only one entry with Gettext. Or maybe Gettext has disambiguation mechanisms?).
http://www.gnu.org/software/gettext/manual/gettext.html#Contexts may be useful to you.
Thanks, Sayamindu
Ok, very interesting. My apologies, Markus, you were completely right.
Is this use of Gettext contexts already implemented in Etoys?
Your first proposal of 'script-tile', 'menu-entry' and 'balloon-help' as contexts seems good to me. How do you proceed? By opening a bug on Mantis and feeding it with changesets when we stumble upon a ambiguous string?
Bye, Séverin
On 11.02.2009, at 11:40, Séverin Lemaignan wrote:
Ok, very interesting. My apologies, Markus, you were completely right.
Is this use of Gettext contexts already implemented in Etoys?
Your first proposal of 'script-tile', 'menu-entry' and 'balloon-help' as contexts seems good to me. How do you proceed? By opening a bug on Mantis and feeding it with changesets when we stumble upon a ambiguous string?
Here is the ticket, pointing to an older instance of the exact same discussion.
https://dev.laptop.org/ticket/6757
The context feature still has not been implemented (neither has the proposed splitting of the pot into smaller chunks).
- Bert -
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Markus Schlager -
Sayamindu Dasgupta -
Séverin Lemaignan