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
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
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 :)
Anyhow, I think can pass around arbitrary character strings in FUDI by encoding them as lists of numbers and using [list tosymbol].
I think it would be very hard to somehow change the textual names of objects and messages in Pd...
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
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
On 2015-04-30 00:53, 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.
are you really talking about translating the *language* of Pd? [1]
if i were a programmer, i would be very surprised (and probably not amused) if my C-code showed up in German or hindi.
otoh, i *did* do some experiments with translated objects a while ago for a performance in the spirit of "patching in tongues" (as matju had once put it).
mfgasdr IOhannes
[1] to end up with something like Fjölnir? http://en.wikipedia.org/wiki/Fj%C3%B6lnir_%28programming_language%29
On 04/30/2015 04:55 AM, IOhannes m zmoelnig wrote:
On 2015-04-30 00:53, Jonathan Wilkes via Pd-list wrote:
Oh, and a general question:
Is there any sensible way to translate creator names and/or method names?
Actually, let me back up...
I'm very interested to know the cost of having English object/method names to Pd users who aren't native speakers. I'm especially interested to hear about the cost of English object/method names when teaching someone Pd who doesn't speak or read English at all.
In short-- if it's a hindrance, I think I may have a way to do i18n for object names that doesn't impact Pd's performance in any significant way.
If, on the other hand, they aren't actually that big an obstacle, then maybe the point is moot.
Does anyone have experience with non-native or non-English speaking students that would shed some light on this?
If I were trying to use software translated from another language, I'd definitely want that feature.
are you really talking about translating the *language* of Pd? [1]
Possibly, but almost certainly not in the way you mean it.
if i were a programmer, i would be very surprised (and probably not amused) if my C-code showed up in German or hindi.
I'm interested in internationalization, which I know is a broad topic. But I can say if your C-code shows up in a different language, and you cannot simply click a button or set a flag to change it back, you most certainly are witnessing localization that is not part of a (workable) i18n system.
I'm not interested in ad hoc or piecemeal localization efforts.
otoh, i *did* do some experiments with translated objects a while ago for a performance in the spirit of "patching in tongues" (as matju had once put it).
If this was part of an i18n effort, could you describe your i18n system?
-Jonathan
mfgasdr IOhannes
[1] to end up with something like Fjölnir? http://en.wikipedia.org/wiki/Fj%C3%B6lnir_%28programming_language%29
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 05/01/2015 03:18 AM, Jonathan Wilkes via Pd-list wrote:
On 04/30/2015 04:55 AM, IOhannes m zmoelnig wrote:
On 2015-04-30 00:53, Jonathan Wilkes via Pd-list wrote:
Oh, and a general question:
Is there any sensible way to translate creator names and/or method names?
Actually, let me back up...
I'm very interested to know the cost of having English object/method names to Pd users who aren't native speakers. I'm especially interested to hear about the cost of English object/method names when teaching someone Pd who doesn't speak or read English at all.
In short-- if it's a hindrance, I think I may have a way to do i18n for object names that doesn't impact Pd's performance in any significant way.
If, on the other hand, they aren't actually that big an obstacle, then maybe the point is moot.
Does anyone have experience with non-native or non-English speaking students that would shed some light on this?
I teach Pd to students at an Austrian university where the majority of the students are either Austrian or German, so they are definitely non-native though have higher education so they do speak English. I haven't heard complaints about the English names so far (but yes, my students probably have a cultural background that does not make them fit exactly to your target audience).
btw, there excel uses i18n keywords for programming. but then excel has a lot less culturally loaded keywords that Pd (and how do you deal with that?)
If I were trying to use software translated from another language, I'd definitely want that feature.
are you really talking about translating the *language* of Pd? [1]
Possibly, but almost certainly not in the way you mean it.
i would be interested in the way you mean it then.
otoh, i *did* do some experiments with translated objects a while ago for a performance in the spirit of "patching in tongues" (as matju had once put it).
If this was part of an i18n effort, could you describe your i18n system?
no it was not part of an i18n effort. it was meant to be part of an artistic performance on the topic if with (il)legibility of code, and the translated objects would actually have been a way to obfuscate the code. in the end i didn't use it...
gmfdsr IOhannes
On 02/05/15 03:54, IOhannes m zmölnig wrote:
no it was not part of an i18n effort. it was meant to be part of an artistic performance on the topic if with (il)legibility of code, and the translated objects would actually have been a way to obfuscate the code. in the end i didn't use it...
I liked the rendering in braille you did for a performance I saw in Perth ... the obfuscation of the details while still revealing some of the process worked nicely, and braille lent a kind of odd binary look to the patch.
Simon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Have you read Matjus paper from 2011? https://www.uni-weimar.de/medien/wiki/PDCON:Conference/Self-Modifying_Help_P...
On 04/30/2015 07:41 AM, Jonathan Wilkes via Pd-list 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
On 04/30/2015 08:36 AM, Max wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Have you read Matjus paper from 2011? https://www.uni-weimar.de/medien/wiki/PDCON:Conference/Self-Modifying_Help_P...
Didn't read the paper until now, but I'm familiar with the implementation. I think I may have even suggested it to Hans as an alternative to the unwieldy PDDP template. (But matju's system, though more usable, is itself quite cumbersome.)
But I don't see any hooks into his system for doing translations of the section headers/subheadings (abstraction arguments), or the explanatory content (comments).
Also in general, I think it's makes more sense to put translatable content inside reflowable widgets than to try to hack absolutely-positioned elements to concoct a relative positioning system.
-Jonathan
On 04/30/2015 07:41 AM, Jonathan Wilkes via Pd-list 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
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iEYEARECAAYFAlVCIcoACgkQ3EB7kzgMM6J9ggCfa15jtbwX4U7smivDAq6urmvr BuwAn1ChEz37gIxiOR0f/LmfOwmUZNn/ =Rfgu -----END PGP SIGNATURE-----
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jonathan Wilkes -
Max -
Miller Puckette -
Simon Wise