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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list