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

[Korakurider]

On Tue, May 18, 2010 at 2:27 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> Am 17.05.2010 um 22:22 schrieb Korakurider:
>>
>> On Tue, May 18, 2010 at 1:58 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>
>>> 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)
>
> Why? It is becoming part of Etoys. Its tiles should be translated along with the other tiles.
   DrGeoII has its own package and its own domain, no?

>
>> + 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.
>
> For efficiency it could have one dictionary with all the translations.
   By current design each domain has its own dictionary (MOFile).
   Are you saying all splitted POs could be collapsed to one domain?

   And my understading is that you claimed by splitting of domain we
will have less need of context support.   I am really confused here...

/Korakurider
>
> - Bert -
>
>> 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
>>>
>
>
>
> _______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>