[#SQ-139] Ambiguous translation strings - dashboard

squeakland

Ambiguous translation strings

Created: 07/Mar/09 05:10 AM Updated: 06/Sep/10 05:56 AM

Component/s:

etoys, translation

Fix Version/s:

future release

Time Tracking:

Not Specified

File Attachments:

etoys_ambiguous_string.txt (38 kB)
2.

proto1.zip (32 kB)

Description

« Hide

From TRAC 6757 (gdsteiner, March 2008)

There are several strings in etoys.po which need 2 different translations. For more details please see the thread starting with http://lists.laptop.org/pipermail/localization/2008-March/000726.html

Most of the strings we couldn't translate well into german are used in script tiles AND halo/menus (for a list please simply check the etoys vocabulary summary).

Attached please find also a list with ambiguous etoys translations strings from the actual etoys.po on Pootle. This is a manually generated list to show examples for problematic strings. It is possible to reduce the list with some discussion about details.

Dangerous strings are

1. all strings which are used in more than one place, especially those which are used in script tiles AND halo/menus.

2. Basic/General strings as "copy", "clear", "none", "quit", "save", next, "previous", "last", ... 3. Strings, which are used very often in many different forms ("change font", " change font ", "Change font", "Change font:"), ...

Splitting etoys.po will reduce the conflicts (at least for translators), but also after that a few context- dependent translations will be necessary IMHO.

Sort Order:

[ Permalink | « Hide ]

Scott Wallace added a comment - 07/Mar/09 05:24 AM

I think we should agree on a solution to this problem very soon. Obviously, existing translations need to continue to work, but ideally all new translations will be able to benefit from the disambiguation conventions, and fixups of problematical strings in existing translations could get started as well.

[ Permalink | « Hide ]

teefal added a comment - 07/Apr/09 11:30 AM

(from software meet, 6-Apr-2009)

Scott felt this one was a high priority because it was preventing translators from doing their work (#2). Tim characterized the problem as "translation strings are currently one-to-one, but they need to be many-to-one." He then asked if a simple solution would be to append a special sequence, as in "Edit {2}", which gets stripped when the text is displayed. Bert suggested using a resource context instead, though Ted thought there might be some issues with resource contexts. The group decided to put the issue in M1 and decide the approach later.

[ Permalink | « Hide ]

korakurider added a comment - 09/Aug/09 11:47 PM

Experimental stuff was posted as http://lists.squeakland.org/pipermail/etoys-dev/2009-August/003439.html
This prototype is trying to disambigify by using method selector of sender of #translated/#translatedNoop as msgctxt (based on Bert's idea). But the disambiguation method doesn't work if string with #translatedNoop is passed to other method and get #translated. So the prototype introduce new variant of #translated/#translatedNoop with manually specified msgctxt.

[ Permalink | « Hide ]

Scott Wallace added a comment - 21/Aug/09 05:24 PM

Attached Korakurider's fileouts that accompanied the following email he sent to etoys-dev on 3 august 2009:

Hi all.
For http://tracker.squeakland.org/browse/SQ-139 ,
I am playing with prototype of msgctxt support in Etoys and want to
discuss with you about this.

Changesets:
1) trnCtxCore-KR msgctxt support for translation engine

2) transCtxSelector-KR To use selector name of method that sender of
#translated and #translatedNoop as msgctxt

3) transCtxExplicit-KR
#translatedWithContext:
and #translatedNoopWithContext:
-- variant of #translated and #translatedNoop
with manually specified msgctxt

4) Using #translatedWithCtx: and #translatedNoopWithContext.
ex1VocaCore-KR
ex2Voca-KR
ex3Sound-KR
ex4Halo-KR
ex5Parts-KR

**How to try it:

   1) Build experimental image
1.1) Grab fresh developer image and update to the latest.
1.2) Apply changesets 1)-4) to the image
1.3) Download the latest PO file for you language from
http://translate.sugarlabs.org/
1.4) Switch locale to your language.
1.5) Open LanguageEditor and load the PO of 1.3) with
"gettext import" functionality.

   2) Generate PO with msgctxt
Evaluate this:

GetTextExporter2 new exportTranslator:
(InternalTranslator newLocaleID: LocaleID current).

Generated PO is at po/etoys/$(LANG).po under your image.

   3) Save image and exit.

   4) Explore and edit PO
    4.1) Generated PO is like this:

#: Morphic-Kernel,_Morph>>additionsToViewerCategoryBasic
msgctxt "Morph>>additionsToViewerCategoryBasic"
msgid "y"
msgstr " (... some translation ...)"

You could see new statement "msgctxt" with name of selector where
the string is located.
If same string has multiple occurrences, each has its msgctxt/msgid
specification. and you could supply different translation for each
occurrences.

4.2) compile MO
msgfmt -o etoys.mo yourpofile

and place etoys.mo to
                     locale/$(LANG)/LC_MESSAGES
              under your image.

    5) restart Etoys with the changes, switch to your language,
and check how translation is executed.

**Manually specifying msgctxt

For some strings with #translatedNoop, #translated is applied in
other location and "selector as msgctxt" doesn't work.
It is needed to manually specify msgctxt. "What as msgctxt"
needs to be negotiated between providers(#translatedNoopWithContext:)
and consumers(#translatedWithContext:).

       Source code become ugly because there are many occurrences of
such use case.
       But I couldn't think of better idea.

/Korakurider

[ Show » ]

Scott Wallace added a comment - 21/Aug/09 05:24 PM Attached Korakurider's fileouts that accompanied the following email he sent to etoys-dev on 3 august 2009: Hi all. For http://tracker.squeakland.org/browse/SQ-139 , I am playing with prototype of msgctxt support in Etoys and want to discuss with you about this. Changesets: 1) trnCtxCore-KR msgctxt support for translation engine 2) transCtxSelector-KR To use selector name of method that sender of #translated and #translatedNoop as msgctxt 3) transCtxExplicit-KR #translatedWithContext: and #translatedNoopWithContext: -- variant of #translated and #translatedNoop with manually specified msgctxt 4) Using #translatedWithCtx: and #translatedNoopWithContext. ex1VocaCore-KR ex2Voca-KR ex3Sound-KR ex4Halo-KR ex5Parts-KR **How to try it: 1) Build experimental image 1.1) Grab fresh developer image and update to the latest. 1.2) Apply changesets 1)-4) to the image 1.3) Download the latest PO file for you language from http://translate.sugarlabs.org/ 1.4) Switch locale to your language. 1.5) Open LanguageEditor and load the PO of 1.3) with "gettext import" functionality. 2) Generate PO with msgctxt Evaluate this: GetTextExporter2 new exportTranslator: (InternalTranslator newLocaleID: LocaleID current). Generated PO is at po/etoys/$(LANG).po under your image. 3) Save image and exit. 4) Explore and edit PO 4.1) Generated PO is like this: #: Morphic-Kernel,_Morph>>additionsToViewerCategoryBasic msgctxt "Morph>>additionsToViewerCategoryBasic" msgid "y" msgstr " (... some translation ...)" You could see new statement "msgctxt" with name of selector where the string is located. If same string has multiple occurrences, each has its msgctxt/msgid specification. and you could supply different translation for each occurrences. 4.2) compile MO msgfmt -o etoys.mo yourpofile and place etoys.mo to locale/$(LANG)/LC_MESSAGES under your image. 5) restart Etoys with the changes, switch to your language, and check how translation is executed. **Manually specifying msgctxt For some strings with #translatedNoop, #translated is applied in other location and "selector as msgctxt" doesn't work. It is needed to manually specify msgctxt. "What as msgctxt" needs to be negotiated between providers(#translatedNoopWithContext:) and consumers(#translatedWithContext:). Source code become ugly because there are many occurrences of such use case. But I couldn't think of better idea. /Korakurider

[ Permalink | « Hide ]

Bert Freudenberg added a comment - 10/May/10 03:59 PM

We'll split up the po files for the next release. Do we still need the contexts too?

[ Permalink | « Hide ]

korakurider added a comment - 10/May/10 10:51 PM

>We'll split up the po files for the next release. Do we still need the contexts too?

Splitting Etoys voca from other "usual" strings should resolve many of conflict of translation of short phrase. But L10n community (including German translation team) could review sample POs and evaluate if the splitting works very well.