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

[Korakurider]

On Tue, May 18, 2010 at 2:57 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> Am 17.05.2010 um 22:37 schrieb 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?
>
> Tiles are currently defined in 11 packages. We still want to bundle them into one PO file. Why are you worried about having tiles from 12 packages in that PO instead of 11?

    OK.   My original thought was that Etoys-tiles has strings of only
base facility and each package PO includes tile stuff, so that add-on
package doesn't affect base POs and make it easy to add package in
dynamic manner (like Hilaire wrote for DrGeoII).

  Then DrGeoII will have two variants of POs/MOs (Etoys version and
Pharo version), that might be headache for Hilaire... or tweak needed
in compatibility package.

>
>>>> + 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).
>
> Yes.
>
>>   Are you saying all splitted POs could be collapsed to one domain?
>
> No. Only to speed up searching for phrases that are not found in their own domain. To save space, we could also iterate through all domains, but that takes a lot longer than caching all in in place.

  Each MOFile has one-to-one mapping dictionary and fallback requires
multiple trials against other dictionary, so additionally we could
have one global dictionary for fallback, right?
  How about search order, so we could collapse all of MOs into one
one-to-one mapping dictionary.

/Korakurider

>
>>   And my understading is that you claimed by splitting of domain we
>> will have less need of context support.   I am really confused here...
>
> This is *only* for the phrases that are *not* found in their. This is not the normal case at all. So I still hope that would help reduce the need for context (which would still be good to have anyway).
>
>> /Korakurider
>
> - Bert -_______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>