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 https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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 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@gmail.com wrote:
I'll implement any *clear* spec for multi-language help patches someone comes up with with the following constraints:
- it separates design from content.
- in only requires documentation writers to care about content.
- it does not pigeonhole help patches into having a single, ugly design
- documentation writers will be guaranteed that whatever they write, it won't
overlap patch content. 5. it is maintainable and scalable
Sounds like .html.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list