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