[PD] multi-language help patches

[Lucas Cordiviola]

>
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.
Mensaje telepatico asistido por maquinas.

From: danomatika at gmail.com
Date: Fri, 26 Feb 2016 14:33:59 -0700
To: jancsika at yahoo.com
CC: pd-list at lists.iem.at
Subject: Re: [PD] multi-language help patches

I think what implying is that maybe Pd *doesn’t* need to handle it. Simply, Pd could open a local webpage, similar to how the Processing “Find in reference” context menu option works when highlighting a function in the editor.
Not to say you/we can’t work out a file format/system to handle alot of this, but I’m thinking that html reference already works well for many other contexts an doesn’t require building new formats/systems to solve alot of the same problems.

--------
Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com



On Feb 26, 2016, at 2:08 PM, Jonathan Wilkes <jancsika at yahoo.com> wrote:html could be leveraged, but I'm really looking for a spec for how Pd 
handles 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 in 
a directory and fetched when needed?  Etc.
-Jonathan
 

    On Friday, February 26, 2016 1:02 PM, Dan Wilcox <danomatika at gmail.com> wrote:
  

 I'll implement any *clear* spec for multi-language help patches someone comes up with 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't overlap patch content.5. it is maintainable and scalableSounds like .html.
--------Dan Wilcox at danomatikadanomatika.comrobotcowboy.com
_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


     

_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160226/c59ec5f5/attachment-0001.html>