[PD] multi-language help patches

[Esteban Viveros]

Yes... These way seems to some 99% of the auto learning issues about help
translations... Much more I can imagine before this thread..

Em sáb, 27 de fev de 2016 15:13, Jonathan Wilkes via Pd-list <
pd-list at lists.iem.at> escreveu:

> > I feel one of the best aspects of PD are the examples via help patches
> so maybe splitting things up outside of PD might work against that?
>
> That is definitely a great feature.  If there's a way to keep that and add
> sane multi-language support, that would
> be the way to go.
>
> -Jonathan
>
>
> On Friday, February 26, 2016 7:08 PM, Dan Wilcox <danomatika at gmail.com>
> wrote:
>
>
> Also, my thinking is going in this direction as we’re dealing with the
> same issues in the OpenFrameworks community. My uni department just hosted
> an OF DocSprint last weekend and we spent a good amount of time wrangling
> how best to integrate a Markdown + Doxygen generated reference system.
>
> Of course pure data patch files and C++ source files are somewhat
> different, but I feel there are the same issues to solve such as what
> requires the most maintenance, works on all platforms, and is easy for non
> developer contributors to use. It’s one thing to build a custom system (we
> did) and quite another to get people to pitch in and fill the content in. I
> just wouldn’t want anyone to spend a lot of time making something
> admittedly cool and built into the canvas but, in the end, may not be
> leveraged by the community the same way a portable, easy to edit, cross
> platform standard might.
>
> --------
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
> On Feb 26, 2016, at 5:01 PM, Dan Wilcox <danomatika at gmail.com> wrote:
>
>
> Ok, so which html reference system should I leverage here?
>
>
> Probably something using css and an html template that make it easy for
> people to fill out. I’d say 1 main html file for each object to document w/
> room for sub pages if needed. Different languages can live in different
> folders.
>
> The nice thing about this approach is lots of people can edit html, there
> are plenty of designers, the files can be rendered by pretty much anything,
> etc. Another option is to have a templating system that uses Markdown, etc
> and just renders to html. It can then live in it’s own source repository
> for shared work and be used as a basis for online as well as distributed
> documentation.
>
> Maybe a good start would be to look at the pure data object database/wiki
> that is around somewhere. I can’t find the link off the top of my head.
>
> Where will
> the html files get stored, and how do we get from clicking the link in the
> help patch (I'm assuming we're still using the current help patches to
> show
> a simple demo of the object) to opening the html doc in the correct
> language?
>
>
> Just like opening a help patch with a context menu option or maybe links
> we can open from the patch itself. Use the current help paths for searching
> and use tcl to launch the path in the system web browser if found.
>
> I’d say the most useful thing would be add linking between patches and
> external files (html, etc) in general. I believe Hans had this in extended
> for the pd-doc stuff.
>
> I’m suggesting this approach partially so you/we don’t end up reinventing
> the wheel. A custom, integrated system would be *nice* but I feel that will
> require too much backend work to build and them probably too much work to
> maintain/extend in the future. HTML+CSS has the option of being loaded into
> a web view within TK I imagine, so another option would be a side pane or
> extra window that can open up right in PD. I’d suggest staying away from
> building extra widgets etc to render a custom approach within the patch
> itself.
>
> --------
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
> On Feb 26, 2016, at 4:44 PM, Jonathan Wilkes <jancsika at yahoo.com> wrote:
>
>
> -Jonathan
>
>
> On Friday, February 26, 2016 4:34 PM, Dan Wilcox <danomatika at gmail.com>
> wrote:
>
>
> 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 design
> 4. 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
> danomatika.com
> robotcowboy.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/20160227/1abca0f1/attachment-0001.html>