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