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@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 <danomat...@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 <danomat...@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 <jancs...@yahoo.com> wrote: > > > -Jonathan > > > On Friday, February 26, 2016 4:34 PM, Dan Wilcox <danomat...@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 <jancs...@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 <danomat...@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@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > > > > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list