[Etoys] How to translate with context for Etoys

[Korakurider]

Hi All.

Etoys have >4000 translatable phrases.  Some phrases are used at
multiple locations and some need to be translated differently for each
occurrence.
We have been discussing about the issue.
Please see previous discussions started from
http://lists.laptop.org/pipermail/localization/2008-March/000742.html

Apparently gettext has feature for such situation: context.
The usecase would be:
  1) When POT extractor (GetTextExporter2) hit message send of
#translated/#translatedNoop (or additional selector) and write record
to POT, decides its context appropriately and write "msgctxt" line
with context information.

  2) #translated (or additional method) decides context for the
receiver string and
look up translations with string and context.  Note the context used
to look up translation must be equal to the extracted one in POT by
1).  Otherwise look up fail.


Now our problem is how to decide context on POT export and on
execution of #translated.

A couple of solutions have been proposed:

P1)
  To introduce #translatedInContext: (or like that) and manually
specify context.
  May be standadizing of how to express context would be needed.
  KDE folks have the syntax for this objective.  Markus Schlager
proposed how to
  express context for strings in user interface. (I will forward his
proposal in another mail)


P2)
   Not to introduce additional method for translation;
   name of method where #translate sent is automatically extracted as msgctxt.
   #translated uses name of method where receiver string placed as context to
   translate.


Both proposals work for trivial case like
   'literal' #translated

But context for receiver of #translatedNoop also need to be decided
and it is difficult.  Actually native GNU gettext doesn't have variant
of gettext_noop with that context can be specified, and we need to
"invent" our own one.
I am stuck here.  Any idea will be really appreciated.

----
Pro of P2) : Implementation effort from developer would be minimum
because one unfiied rule to decide context will be applied.
Con:  there are several important cases that the rule can't be applied.

** Example1 **
Every morph class have #descriptionForPartsBin that returns name and
baloon help for the morph in parts bin as untranslated.  Actual
translation is executed in #translatedQuads and locations are very
different.
In this case, P2) can't be applied.  P1) seems natural to me: each
string itself to translate have its context (#translatedNoop returns
such string), and #translate can ask the string about its context.

** Example2 **
please review #initializeStandardVocabulary: there are bunch of
literals with #translatedNoop.  The translation of these literals is
executed in so many places that one can't track.


/Korakurider