[PD] help patch translations

[Jonathan Wilkes]

On 04/29/2015 07:16 PM, Miller Puckette wrote:
> Hi Jonathan -
>
> I confess I don't have any idea how what you're describing is possible... but
> then I've seen people do plenty of stuff I wouldn't have thought possible in
> Pd before :)

A help patch would have the following structure:

[header]
[canvas]
[footer]

The header and footer hold text that can reflow like a webpage can (or like
Pd's printout window).  That's where one would display the translated text
for the help patch.  This way it doesn't matter how much space the 
translated
text takes up, because it is displayed above or below the canvas proper.

The content of the translation is in separate files-- one for each language.
So when you have a help patch, Pd checks if there's a language file for the
current locale.  If there is, it uses it to populate the header and 
footer.  (Additionally,
if there's a symbol to be displayed as an iemgui label it is dispatched 
to Pd.)

At least in the GUI port I'm working on, the cost to a patch window is
literally two <div> elements which remain un-rendered unless there's 
translation
data.  I guess the question is whether to do this purely on the GUI 
side, in which
case the Pd engine wouldn't be affected at all.

(Having just written that last sentence, I think the answer is yes. :)

The potential downside I see to this approach is that if patch authors want
to make their help patches ready for i18n from the outset, they must have at
least two source files-- one for the Pd patch, and one with the 
header/footer
data.  But the alternative would be stuffing all languages into a single 
patch,
which would guarantee a load-time impact if internationalization is 
successful.

-Jonathan

>
> Anyhow, I think can pass around arbitrary character strings in FUDI by
> encoding them as lists of numbers and using [list tosymbol].

Thanks, I forgot about that object.  That would certainly work, but at the
cost of making the translation data unreadable.

>
> I think it would be very hard to somehow change the textual names of objects
> and messages in Pd...

Or maybe just a handful of gop abstractions with an imoji on them. The 
minimum
number to be turing complete, then see what happens...

-Jonathan

>
> cheers
> Miller
>
>
> On Wed, Apr 29, 2015 at 06:53:49PM -0400, Jonathan Wilkes via Pd-list wrote:
>> Oh, and a general question:
>>
>> Is there any sensible way to translate creator names and/or method names?
>>
>> If I were trying to use software translated from another language, I'd
>> definitely want that feature.  It seems like that would theoretically be
>> possible, but I haven't thought about it in any detail.
>>
>> -Jonathan
>>
>>
>> On 04/29/2015 06:41 PM, Jonathan Wilkes wrote:
>>> Hi Miller,
>>> I've got a fairly fleshed out idea for how to do internationalized help
>>> patches in Pd.
>>>
>>> It would be nice to store the translations as files containing FUDI
>>> messages, like this:
>>>
>>> description something something;
>>> outlet_0 float translated description of what a float arriving at the 0th
>>> inlet does;
>>> outlet_0 list etc...;
>>> demo-slider label foo;
>>> demo-bang label bar;
>>>
>>> The benefit is that one could actually parse the translation data using Pd
>>> itself.  Here, the description and outlet data could be forwarded to the
>>> gui (to format in a footer that reflows with the width of the window).
>>> Additionally, the "demo" slider and bang could be sent to iemgui receives
>>> to get a translated label. (Perhaps prepending a "$0-" to guard against
>>> nameclashes in other open patch windows.)
>>>
>>> The problem of course is that FUDI is too brittle for arbitrary text.
>>> It's too easy to lose data, and too difficult to try to remember all the
>>> ways in which numbers, commas, semis, decimals, dollarsigns, and "dropped"
>>> keycodes can result in a data loss. Not impossible to work around, but
>>> burdensome for doc writers trying to concentrate on translating
>>> explanatory text.
>>>
>>> Is there any way to read or write FUDI-- perhaps with [text]-- and tell
>>> the parser to interpret everything after the nth atom as a single symbol?
>>>
>>> If not, I can just store the translation data as JSON (which I'm already
>>> doing for the gui interfaction translations).  In that case I'd just read
>>> the translations from the GUI side, and forward any iemgui label messages
>>> on to Pd.
>>>
>>> -Jonathan
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>