[Etoys] translation issue in addTranslatedList:

[Bert Freudenberg]

Scott,

this would mean one had to explicitly add special cases to  
GetTextExporter. Just slapping #translatedNoop onto the literal seems  
way more flexible. Also, it indicates right in the code that these  
strings are going to be translated.

Do we have a use case where we want to append #translatedNoop but do  
*not* want every embedded literal string to be translated?

- Bert -

On Sep 27, 2007, at 11:19 , Scott Wallace wrote:

> Hi, Korakurider,
>
> This is getting closer, but it still would require changes to all of
> those 25 methods that call #addTranslatedList:, and also would
> spuriously grab literals from many other methods that happen to have
> big literals in them but which have nothing to do with
> #addTranslatedList:.
>
> I'm still quite willing to append #translatedNoop calls to the array
> literals in the 25 methods, but I think there's perhaps a better way
> that requires writing only one new method and making a one-line
> modification to one other method, and which might be more generally
> useful in the translation regime in any case.
>
> What I suggest is that one implement a method named something like:
>
>      GetTextExporter2 >>
> appendStringsAtPositions:ofArgsInSendersOf:into:
>
> whose first argument is an index-list and whose second argument is a
> selector, and whose third argument is the categories dictionary
> common to the protocol of all the appendXXX methods in  
> GetTextExporter2.
>
> The one guaranteed use-case of this method would be the addition of
> the following line to the code for GetTextExporter2 >>
> appendTranslations:categories:
>
>    self appendStringsAtPositions: #(1 3) ofArgsInSendersOf:
> #addTranslatedList: into: categories.
>
> The job of appendStringsAtPositions:ofArgsInSendersOf:into: would be
> to retrieve all senders of the given selector, scan the parse tree of
> each retrieved method, locate every send of the given selector within
> the method node, find out if the argument of the send is an array
> literal, and, if it is, iterate across that array, and for each
> element of it which *itself* is an array, pick off the strings to be
> translated from the index positions requested in the call, and
> integrate them into the ongoing categories structure.
>
> Isn't this feasible?  Or am I missing something?
>
> If we come across other situations where translatable strings are
> buried within elements of complex literal arrays we could then handle
> those calls in the same way.
>
>
> Cheers,
>
>    -- Scott
>
>
>
> On Sep 26, 2007, at 9:59 PM, korakurider wrote:
>
>> Hi, Takashi, Scott.
>>
>> --- Takashi Yamamiya <tak at metatoys.org> wrote:
>>> I think it will work well if you implement
>>> TranslatedReceiverFinder correctly.
>>
>> Proposed patch is attached.  But I am not sure whether
>> this is good approach after writing down the patch:
>> As tuple format of array is specific to each use case I
>> had to assume only #addTranslatedList:, which I don't
>> like.
>>
>> /Korakurider