[etoys-dev] Re: Need for translation in DrGeo

[Korakurider]

On Tue, May 18, 2010 at 1:58 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> Am 17.05.2010 um 21:42 schrieb Korakurider:
>>
>> On Tue, May 18, 2010 at 1:04 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>> Am 17.05.2010 um 18:37 schrieb Korakurider:
>>>>
>>>> On Tue, May 18, 2010 at 4:05 AM, Ricardo Moran <richi.moran at gmail.com> wrote:
>>>>
>>>>> What is the usage of #translatedNoop currently? I see that it has an empty
>>>>> implementation so I guess it's just used to mark strings but when are those
>>>>> strings translated?
>>>>   Yes, #translatedNoop is just marking string as translatable and let
>>>> GetTextExporter2 extract the string to POT.   Actual translation occur
>>>> only in #translated.   See "4.7 Special Case of Translatable Strings"
>>>> in http://www.gnu.org/software/gettext/manual/gettext.html.
>>>>
>>>>> I don't understand what you're saying about each string knowing its domain
>>>>> by marking it #translatedNoop.
>>>>   The crazy idea was ...
>>>>   Currently method body of #translatedNoop is empty.  But in the
>>>> method translation domain for the string could be decided with sender
>>>> of #translatedNoop and could be stored in receiver string.
>>>
>>> Now that indeed *is* a crazy idea ;)
>>> I have a simpler one:
>>>
>>> First try to look up the domain in the sender of #translated, as usual. Then, if the phrase was not found there, look in all the other domains.
>>>
>>> That should keep all existing translations working.
>>   Yes, it works like **current** implementation;
>>   But if multiple domains has same translatable string and
>> translations are different among domains, result of translation cannot
>> be deterministic.
>>
>> /korakurider
>
> Indeed, but I would only see that as a fallback. The general case would be for the word to be found in the domain of the #translated sender.
>
> IMHO it is highly unlikely for a phrase to not be found in its regular domain, *and* be defined in multiple domains, *and* having those translations actually be different. And *if* there was such a case, it could be solved by using #translatedInDomain: but I doubt this is actually necessary.

How about walking through DrGeoII's situation describe in
http://lists.squeakland.org/pipermail/etoys-dev/2010-May/004768.html
for test case?
(Here "multiple domains" condition has to be relaxed ;)

+ I think we want strings in vocaburary for DrGeoII belong to not
Etoys-tile but DrGeoII domain.  (GetTextExporter2>>appendVocabularies:
has to be tweaked)
+ currently voca wording is executed for default domain
 but it should be DrGeoII domain but translator cannot know.
 Domain is determined like late-binding.
 I don't think #translatedInDomain: can be used unless actual doman
can be passed.

 So translator has to try all domains sequentially.

What I want to say is that such case is not special if we will split domains
and your fallback scenario has to be used too frequently.

(then my "crazy" idea come in :-)
/Korakurider

>
> - Bert -
>
>
> _______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>