> M-L-Help files can be done translating each help file and saving it with a name like “metro-help-ES.pd” or “metro-help-FR.pd” then telling pd to add the -ES or -XX to the english helpfile name.
That's not maintainable:
1. Revisions to the demo part of the help patch would have to be applied
manually, to as many patches as there are languages.
2. In almost all cases the translater has to mess around with the positioning
of objects to make sure that the comments don't overlap.
3. Currently, Pd doesn't even give you a visual cue for the max width and
height of a comment object at a particular font size, so the translater can't even know whether the comments they are manually positioning will in fact collide on
someone else's system.
These 3 points could be part of the job, once the comments have been translated to that patch you can download it and correct it, and upload.
4. Even if all the points above weren't an issue, the design becomes baked
in and isn't user-friendly for people who want to zoom in to make the text bigger.
I've notice this with the GUI port-- if you zoom in on a PDDP patch the help
text extends past the window dimensions, causing vertical scrollbars which are
the worst in terms of readability. So now you have to manually resize the
window so that the zoomed text fits inside it. Not bad for reading a single patch,
but try that 100 times esp. on one of those awful linux wm's that give you a
2x2 hotspot for resizing the window.
This point I have no idea.
I have nothing against html nor to the *help-xx.pd.
Also both will be much easier to implement as an online option.
On Feb 26, 2016, at 2:08 PM, Jonathan Wilkes <jancsika@yahoo.com> wrote:html could be leveraged, but I'm really looking for a spec for how Pdhandles it. Is it a GUI widget? An abstraction? A canvas method? A new"#" directive?Do the translations get saved along with the help patch, or are they stored ina directory and fetched when needed? Etc.-Jonathan
On Friday, February 26, 2016 1:02 PM, Dan Wilcox <danomatika@gmail.com> wrote:
I'll implement any *clear* spec for multi-language help patches someone comes upwith with the following constraints:1. it separates design from content.2. in only requires documentation writers to care about content.3. it does not pigeonhole help patches into having a single, ugly design4. documentation writers will be guaranteed that whatever they write, it won'toverlap patch content.5. it is maintainable and scalableSounds like .html.
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list