Re: [PD] multi-language help patches

2016-03-01 Thread Jonghyun Kim 
It's about translation. Translating project for pd-extended is also dead?
Can Pd vanilla be translated?

https://www.transifex.com/eighthave/puredata/

Thanks,
Jonghyun


On Sat, Feb 27, 2016 at 2:47 AM, Jonathan Wilkes via Pd-list <
pd-list@lists.iem.at> wrote:

> Hi list,
> I'm pulling this out of the monster thread because it's something I've
> been thinking
> about for awhile:
>
> > Another feature I miss is multi-language comment object. Enabling
> multi-language Help files, even multi-language patch comments can be lot
> useful!
>
> 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
>
> -Jonathan
>
> ___
> 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

Re: [PD] multi-language help patches

2016-02-29 Thread Lucas Cordiviola 
Probably wikipedia.org can
do object help and object-help patch translation, the most primitive
form could be an screen snapshot of the translated patch, and its
text equivalent inside an   html tag.



But this don't cover the
/2.control.examples, /3.audio.examples /4.data.structures , etc, that
form the powerful help system.



This can be translated
with an FTP server, but it's hard to prevent accidental file
deletion.
Mensaje telepatico asistido por maquinas.

From: emvive...@gmail.com
Date: Sat, 27 Feb 2016 22:21:07 +
Subject: Re: [PD] multi-language help patches
To: lucard...@hotmail.com; pd-list@lists.iem.at

Portuguese translation of help patches are guaranteed! :) 




  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] multi-language help patches

2016-02-27 Thread Esteban Viveros 
Portuguese translation of help patches are guaranteed! :)

Em sáb, 27 de fev de 2016 19:07, Lucas Cordiviola <lucard...@hotmail.com>
escreveu:

> Probably an html server can provide both things, the html help AND the
> translated patch in the same url.
>
>
> Whats important is that in can be completed/translated by users.
>
>
> Wikipedia is the most familiar one to almost everyone. (perhaps I'm wrong
> here, not sure)
>
> Mensaje telepatico asistido por maquinas.
>
> --
> From: lucard...@hotmail.com
> To: pd-list@lists.iem.at
> Date: Sat, 27 Feb 2016 21:33:25 +
>
> Subject: Re: [PD] multi-language help patches
>
> There are chances that we`re welcome at wikipedia.
>
>
>
>
> Mensaje telepatico asistido por maquinas.
>
> --
> From: lucard...@hotmail.com
> To: pd-list@lists.iem.at
> Date: Sat, 27 Feb 2016 21:18:01 +
> Subject: Re: [PD] multi-language help patches
>
> Of course if we`re gonna use wikipedia.org as storage for encoded html
> information of a software we should tell them about it an ask for their
> permission.
>
>
> Probably they say no.
>
>
> So we will be looking for another server.
>
>
> But...
>
> Mensaje telepatico asistido por maquinas.
>
> ----------
> From: lucard...@hotmail.com
> To: pd-list@lists.iem.at
> Date: Sat, 27 Feb 2016 20:37:37 +
> Subject: Re: [PD] multi-language help patches
>
> Eventually the user can make his particularly language translated patch:
>
>
>
> Or it can be obteined with some href and an Id, not sure if its posible:
>
>
> pd_obj...@wikipedia.org
>
>
>
>
> 
>
>
> #N canvas 20 43 698 447 12;
>
> #X floatatom 524 338 0 0 0;
>
> #X floatatom 353 338 0 0 0;
>
> #X floatatom 298 338 0 0 0;
>
> #X floatatom 413 338 0 0 0;
>
> #X floatatom 467 338 0 0 0;
>
> #X obj 524 311 <;
>
> #X obj 298 262 r left;
>
> #X obj 540 267 r right;
>
> #X floatatom 71 335 0 0 0;
>
> #X floatatom 19 334 0 0 0;
>
> #X floatatom 119 335 0 0 0;
>
> #X floatatom 163 334 0 0 0;
>
> #X obj 16 45 &;
>
> #X obj 66 45 |;
>
> #X obj 118 45 &&;
>
> #X obj 169 45 ||;
>
> #X obj 19 307 &;
>
> #X obj 71 308 |;
>
> #X obj 119 308 &&;
>
> #X obj 163 307 ||;
>
> #X text 13 73 uoyhbqrevfg qrepfgvb;
>
> #X obj 19 266 r left;
>
> #X obj 218 266 r right;
>
> #X obj 12 118 >;
>
> #X obj 61 118 >=;
>
> #X obj 114 118 ==;
>
> #X obj 215 119 <=;
>
> #X obj 262 119 <;
>
> #X text 11 153 ouyhqergf eqwrvgupoyhb;
>
> #X obj 298 312 >;
>
> #X obj 353 312 >=;
>
> #X obj 413 312 ==;
>
> #X obj 467 312 <=;
>
> #X text 16 190 piuqgherfpgiuhqerfg qerpfgiuberpigureg erpiuybqepirugbqerg
> qerpiyhbqperiugbqerg qepriyhbqepirgb
>
> piybqergipub iuqberifvuhq[iuerhgfv qifvubqe[riuh[uheqrg piubqrguh
>
> ;
>
> #X floatatom 410 65 0 0 0;
>
> #X obj 410 92 s left;
>
> #X floatatom 481 66 0 0 0;
>
> #X obj 481 94 t b f;
>
> #X obj 481 122 s left;
>
> #X obj 541 122 s right;
>
> #X obj 166 118 !=;
>
> #X text 377 42 ouyvqdev qewrpfgvy;
>
> #X floatatom 202 335 0 0 0;
>
> #X floatatom 246 334 0 0 0;
>
> #X obj 208 46 <<;
>
> #X obj 259 46 >>;
>
> #X obj 202 308 <<;
>
> #X obj 246 307 >>;
>
> #X text 421 383 ouyvqwerfhb version 0.32;
>
> #X connect 5 0 0 0;
>
> #X connect 6 0 29 0;
>
> #X connect 6 0 30 0;
>
> #X connect 6 0 31 0;
>
> #X connect 6 0 32 0;
>
> #X connect 6 0 5 0;
>
> #X connect 7 0 29 1;
>
> #X connect 7 0 30 1;
>
> #X connect 7 0 31 1;
>
> #X connect 7 0 32 1;
>
> #X connect 7 0 5 1;
>
> #X connect 16 0 9 0;
>
> #X connect 17 0 8 0;
>
> #X connect 18 0 10 0;
>
> #X connect 19 0 11 0;
>
> #X connect 21 0 16 0;
>
> #X connect 21 0 17 0;
>
> #X connect 21 0 18 0;
>
> #X connect 21 0 19 0;
>
> #X connect 21 0 46 0;
>
> #X connect 21 0 47 0;
>
> #X connect 22 0 19 1;
>
> #X connect 22 0 18 1;
>
> #X connect 22 0 17 1;
>
> #X connect 22 0 16 1;
>
> #X connect 22 0 47 1;
>
> #X connect 22 0 46 1;
>
> #X connect 29 0 2 0;
>
> #X connect 30 0 1 0;
>
> #X connect 31 0 3 0;
>
> #X connect 32 0 4 0;
>
> #X connect 34 0 35 0;
>
> #X connect 36 0 37 0;
>
> #X connect 37 0 38 0;
>
> #X connect 37 1 39 0;
>
> #X connect 46 0 42 0;
>
> #X connect 47 0 43 0;
>
>
> 
>
> Mensaje telepatico asistido por maquinas.
>
> ---

Re: [PD] multi-language help patches

2016-02-27 Thread Lucas Cordiviola 
Probably an html server
can provide both things, the html help AND the translated patch in
the same url.



Whats important is that in
can be completed/translated by users.



Wikipedia is the most
familiar one to almost everyone. (perhaps I'm wrong here, not sure)
Mensaje telepatico asistido por maquinas.

From: lucard...@hotmail.com
To: pd-list@lists.iem.at
Date: Sat, 27 Feb 2016 21:33:25 +
Subject: Re: [PD] multi-language help patches




There are chances that
we`re welcome at wikipedia.


Mensaje telepatico asistido por maquinas.

From: lucard...@hotmail.com
To: pd-list@lists.iem.at
Date: Sat, 27 Feb 2016 21:18:01 +
Subject: Re: [PD] multi-language help patches




Of course if we`re gonna
use wikipedia.org as storage for encoded html information of a
software we should tell them about it an ask for their permission.



Probably they say no.



So we will be looking for
another server.



But...
Mensaje telepatico asistido por maquinas.

From: lucard...@hotmail.com
To: pd-list@lists.iem.at
Date: Sat, 27 Feb 2016 20:37:37 +
Subject: Re: [PD] multi-language help patches




Eventually the user can
make his particularly language translated patch:






Or it can be obteined with
some href and an Id, not sure if its posible:



pd_obj...@wikipedia.org













#N canvas 20 43 698 447
12;
#X floatatom 524 338 0 0
0;
#X floatatom 353 338 0 0
0;
#X floatatom 298 338 0 0
0;
#X floatatom 413 338 0 0
0;
#X floatatom 467 338 0 0
0;
#X obj 524 311 <;
#X obj 298 262 r left;
#X obj 540 267 r right;
#X floatatom 71 335 0 0 0;
#X floatatom 19 334 0 0 0;
#X floatatom 119 335 0 0
0;
#X floatatom 163 334 0 0
0;
#X obj 16 45 &;
#X obj 66 45 |;
#X obj 118 45 &&;
#X obj 169 45 ||;
#X obj 19 307 &;
#X obj 71 308 |;
#X obj 119 308 &&;
#X obj 163 307 ||;
#X text 13 73 uoyhbqrevfg
qrepfgvb;
#X obj 19 266 r left;
#X obj 218 266 r right;
#X obj 12 118 >;
#X obj 61 118 >=;
#X obj 114 118 ==;
#X obj 215 119 <=;
#X obj 262 119 <;
#X text 11 153 ouyhqergf
eqwrvgupoyhb;
#X obj 298 312 >;
#X obj 353 312 >=;
#X obj 413 312 ==;
#X obj 467 312 <=;
#X text 16 190
piuqgherfpgiuhqerfg qerpfgiuberpigureg erpiuybqepirugbqerg
qerpiyhbqperiugbqerg qepriyhbqepirgb 

piybqergipub
iuqberifvuhq[iuerhgfv qifvubqe[riuh[uheqrg piubqrguh
;
#X floatatom 410 65 0 0 0;
#X obj 410 92 s left;
#X floatatom 481 66 0 0 0;
#X obj 481 94 t b f;
#X obj 481 122 s left;
#X obj 541 122 s right;
#X obj 166 118 !=;
#X text 377 42 ouyvqdev
qewrpfgvy;
#X floatatom 202 335 0 0
0;
#X floatatom 246 334 0 0
0;
#X obj 208 46 <<;
#X obj 259 46 >>;
#X obj 202 308 <<;
#X obj 246 307 >>;
#X text 421 383
ouyvqwerfhb  version 0.32;
#X connect 5 0 0 0;
#X connect 6 0 29 0;
#X connect 6 0 30 0;
#X connect 6 0 31 0;
#X connect 6 0 32 0;
#X connect 6 0 5 0;
#X connect 7 0 29 1;
#X connect 7 0 30 1;
#X connect 7 0 31 1;
#X connect 7 0 32 1;
#X connect 7 0 5 1;
#X connect 16 0 9 0;
#X connect 17 0 8 0;
#X connect 18 0 10 0;
#X connect 19 0 11 0;
#X connect 21 0 16 0;
#X connect 21 0 17 0;
#X connect 21 0 18 0;
#X connect 21 0 19 0;
#X connect 21 0 46 0;
#X connect 21 0 47 0;
#X connect 22 0 19 1;
#X connect 22 0 18 1;
#X connect 22 0 17 1;
#X connect 22 0 16 1;
#X connect 22 0 47 1;
#X connect 22 0 46 1;
#X connect 29 0 2 0;
#X connect 30 0 1 0;
#X connect 31 0 3 0;
#X connect 32 0 4 0;
#X connect 34 0 35 0;
#X connect 36 0 37 0;
#X connect 37 0 38 0;
#X connect 37 1 39 0;
#X connect 46 0 42 0;
#X connect 47 0 43 0;




Mensaje telepatico asistido por maquinas.

From: emvive...@gmail.com
Date: Sat, 27 Feb 2016 19:19:33 +
Subject: Re: [PD] multi-language help patches
To: lucard...@hotmail.com; pd-list@lists.iem.at


Em sáb, 27 de fev de 2016 15:46, Lucas Cordiviola <lucard...@hotmail.com> 
escreveu:



As an sketch:



pd nameoftheobject
@wikipedia.org



pd osc~ or with the
underscore pd_osc~



https://en.wikipedia.org/wiki/pd_osc~



It will be slow to fill
objects but...







>
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.








Totally agree with that
but perhaps that is just for the international english default  (the
standard default help system). Other languages could be HELPED in
html format.



I`ve also proposed the
translation of just the comments in *-help.pd files, but that seems
difficult and language packs...
I think a comment object with better features yet is a great feature, but the 
weighing the high development cost, this html solution for helps, can do the 
community more active once it documentation, maybe,  can privilege the 
http://forum.pdpatchrepo.info for example to promote more organized 
collaboration of learning issues between pd community. 

Mensaje telepatico asistido por maquinas.

Re: [PD] multi-language help patches

2016-02-27 Thread Lucas Cordiviola 
There are chances that
we`re welcome at wikipedia.


Mensaje telepatico asistido por maquinas.

From: lucard...@hotmail.com
To: pd-list@lists.iem.at
Date: Sat, 27 Feb 2016 21:18:01 +
Subject: Re: [PD] multi-language help patches




Of course if we`re gonna
use wikipedia.org as storage for encoded html information of a
software we should tell them about it an ask for their permission.



Probably they say no.



So we will be looking for
another server.



But...
Mensaje telepatico asistido por maquinas.

From: lucard...@hotmail.com
To: pd-list@lists.iem.at
Date: Sat, 27 Feb 2016 20:37:37 +
Subject: Re: [PD] multi-language help patches




Eventually the user can
make his particularly language translated patch:






Or it can be obteined with
some href and an Id, not sure if its posible:



pd_obj...@wikipedia.org













#N canvas 20 43 698 447
12;
#X floatatom 524 338 0 0
0;
#X floatatom 353 338 0 0
0;
#X floatatom 298 338 0 0
0;
#X floatatom 413 338 0 0
0;
#X floatatom 467 338 0 0
0;
#X obj 524 311 <;
#X obj 298 262 r left;
#X obj 540 267 r right;
#X floatatom 71 335 0 0 0;
#X floatatom 19 334 0 0 0;
#X floatatom 119 335 0 0
0;
#X floatatom 163 334 0 0
0;
#X obj 16 45 &;
#X obj 66 45 |;
#X obj 118 45 &&;
#X obj 169 45 ||;
#X obj 19 307 &;
#X obj 71 308 |;
#X obj 119 308 &&;
#X obj 163 307 ||;
#X text 13 73 uoyhbqrevfg
qrepfgvb;
#X obj 19 266 r left;
#X obj 218 266 r right;
#X obj 12 118 >;
#X obj 61 118 >=;
#X obj 114 118 ==;
#X obj 215 119 <=;
#X obj 262 119 <;
#X text 11 153 ouyhqergf
eqwrvgupoyhb;
#X obj 298 312 >;
#X obj 353 312 >=;
#X obj 413 312 ==;
#X obj 467 312 <=;
#X text 16 190
piuqgherfpgiuhqerfg qerpfgiuberpigureg erpiuybqepirugbqerg
qerpiyhbqperiugbqerg qepriyhbqepirgb 

piybqergipub
iuqberifvuhq[iuerhgfv qifvubqe[riuh[uheqrg piubqrguh
;
#X floatatom 410 65 0 0 0;
#X obj 410 92 s left;
#X floatatom 481 66 0 0 0;
#X obj 481 94 t b f;
#X obj 481 122 s left;
#X obj 541 122 s right;
#X obj 166 118 !=;
#X text 377 42 ouyvqdev
qewrpfgvy;
#X floatatom 202 335 0 0
0;
#X floatatom 246 334 0 0
0;
#X obj 208 46 <<;
#X obj 259 46 >>;
#X obj 202 308 <<;
#X obj 246 307 >>;
#X text 421 383
ouyvqwerfhb  version 0.32;
#X connect 5 0 0 0;
#X connect 6 0 29 0;
#X connect 6 0 30 0;
#X connect 6 0 31 0;
#X connect 6 0 32 0;
#X connect 6 0 5 0;
#X connect 7 0 29 1;
#X connect 7 0 30 1;
#X connect 7 0 31 1;
#X connect 7 0 32 1;
#X connect 7 0 5 1;
#X connect 16 0 9 0;
#X connect 17 0 8 0;
#X connect 18 0 10 0;
#X connect 19 0 11 0;
#X connect 21 0 16 0;
#X connect 21 0 17 0;
#X connect 21 0 18 0;
#X connect 21 0 19 0;
#X connect 21 0 46 0;
#X connect 21 0 47 0;
#X connect 22 0 19 1;
#X connect 22 0 18 1;
#X connect 22 0 17 1;
#X connect 22 0 16 1;
#X connect 22 0 47 1;
#X connect 22 0 46 1;
#X connect 29 0 2 0;
#X connect 30 0 1 0;
#X connect 31 0 3 0;
#X connect 32 0 4 0;
#X connect 34 0 35 0;
#X connect 36 0 37 0;
#X connect 37 0 38 0;
#X connect 37 1 39 0;
#X connect 46 0 42 0;
#X connect 47 0 43 0;




Mensaje telepatico asistido por maquinas.

From: emvive...@gmail.com
Date: Sat, 27 Feb 2016 19:19:33 +
Subject: Re: [PD] multi-language help patches
To: lucard...@hotmail.com; pd-list@lists.iem.at


Em sáb, 27 de fev de 2016 15:46, Lucas Cordiviola <lucard...@hotmail.com> 
escreveu:



As an sketch:



pd nameoftheobject
@wikipedia.org



pd osc~ or with the
underscore pd_osc~



https://en.wikipedia.org/wiki/pd_osc~



It will be slow to fill
objects but...







>
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.








Totally agree with that
but perhaps that is just for the international english default  (the
standard default help system). Other languages could be HELPED in
html format.



I`ve also proposed the
translation of just the comments in *-help.pd files, but that seems
difficult and language packs...
I think a comment object with better features yet is a great feature, but the 
weighing the high development cost, this html solution for helps, can do the 
community more active once it documentation, maybe,  can privilege the 
http://forum.pdpatchrepo.info for example to promote more organized 
collaboration of learning issues between pd community. 

Mensaje telepatico asistido por maquinas.


  
___

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 


__

Re: [PD] multi-language help patches

2016-02-27 Thread Lucas Cordiviola 
Of course if we`re gonna
use wikipedia.org as storage for encoded html information of a
software we should tell them about it an ask for their permission.



Probably they say no.



So we will be looking for
another server.



But...
Mensaje telepatico asistido por maquinas.

From: lucard...@hotmail.com
To: pd-list@lists.iem.at
Date: Sat, 27 Feb 2016 20:37:37 +
Subject: Re: [PD] multi-language help patches




Eventually the user can
make his particularly language translated patch:






Or it can be obteined with
some href and an Id, not sure if its posible:



pd_obj...@wikipedia.org













#N canvas 20 43 698 447
12;
#X floatatom 524 338 0 0
0;
#X floatatom 353 338 0 0
0;
#X floatatom 298 338 0 0
0;
#X floatatom 413 338 0 0
0;
#X floatatom 467 338 0 0
0;
#X obj 524 311 <;
#X obj 298 262 r left;
#X obj 540 267 r right;
#X floatatom 71 335 0 0 0;
#X floatatom 19 334 0 0 0;
#X floatatom 119 335 0 0
0;
#X floatatom 163 334 0 0
0;
#X obj 16 45 &;
#X obj 66 45 |;
#X obj 118 45 &&;
#X obj 169 45 ||;
#X obj 19 307 &;
#X obj 71 308 |;
#X obj 119 308 &&;
#X obj 163 307 ||;
#X text 13 73 uoyhbqrevfg
qrepfgvb;
#X obj 19 266 r left;
#X obj 218 266 r right;
#X obj 12 118 >;
#X obj 61 118 >=;
#X obj 114 118 ==;
#X obj 215 119 <=;
#X obj 262 119 <;
#X text 11 153 ouyhqergf
eqwrvgupoyhb;
#X obj 298 312 >;
#X obj 353 312 >=;
#X obj 413 312 ==;
#X obj 467 312 <=;
#X text 16 190
piuqgherfpgiuhqerfg qerpfgiuberpigureg erpiuybqepirugbqerg
qerpiyhbqperiugbqerg qepriyhbqepirgb 

piybqergipub
iuqberifvuhq[iuerhgfv qifvubqe[riuh[uheqrg piubqrguh
;
#X floatatom 410 65 0 0 0;
#X obj 410 92 s left;
#X floatatom 481 66 0 0 0;
#X obj 481 94 t b f;
#X obj 481 122 s left;
#X obj 541 122 s right;
#X obj 166 118 !=;
#X text 377 42 ouyvqdev
qewrpfgvy;
#X floatatom 202 335 0 0
0;
#X floatatom 246 334 0 0
0;
#X obj 208 46 <<;
#X obj 259 46 >>;
#X obj 202 308 <<;
#X obj 246 307 >>;
#X text 421 383
ouyvqwerfhb  version 0.32;
#X connect 5 0 0 0;
#X connect 6 0 29 0;
#X connect 6 0 30 0;
#X connect 6 0 31 0;
#X connect 6 0 32 0;
#X connect 6 0 5 0;
#X connect 7 0 29 1;
#X connect 7 0 30 1;
#X connect 7 0 31 1;
#X connect 7 0 32 1;
#X connect 7 0 5 1;
#X connect 16 0 9 0;
#X connect 17 0 8 0;
#X connect 18 0 10 0;
#X connect 19 0 11 0;
#X connect 21 0 16 0;
#X connect 21 0 17 0;
#X connect 21 0 18 0;
#X connect 21 0 19 0;
#X connect 21 0 46 0;
#X connect 21 0 47 0;
#X connect 22 0 19 1;
#X connect 22 0 18 1;
#X connect 22 0 17 1;
#X connect 22 0 16 1;
#X connect 22 0 47 1;
#X connect 22 0 46 1;
#X connect 29 0 2 0;
#X connect 30 0 1 0;
#X connect 31 0 3 0;
#X connect 32 0 4 0;
#X connect 34 0 35 0;
#X connect 36 0 37 0;
#X connect 37 0 38 0;
#X connect 37 1 39 0;
#X connect 46 0 42 0;
#X connect 47 0 43 0;




Mensaje telepatico asistido por maquinas.

From: emvive...@gmail.com
Date: Sat, 27 Feb 2016 19:19:33 +
Subject: Re: [PD] multi-language help patches
To: lucard...@hotmail.com; pd-list@lists.iem.at


Em sáb, 27 de fev de 2016 15:46, Lucas Cordiviola <lucard...@hotmail.com> 
escreveu:



As an sketch:



pd nameoftheobject
@wikipedia.org



pd osc~ or with the
underscore pd_osc~



https://en.wikipedia.org/wiki/pd_osc~



It will be slow to fill
objects but...







>
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.








Totally agree with that
but perhaps that is just for the international english default  (the
standard default help system). Other languages could be HELPED in
html format.



I`ve also proposed the
translation of just the comments in *-help.pd files, but that seems
difficult and language packs...
I think a comment object with better features yet is a great feature, but the 
weighing the high development cost, this html solution for helps, can do the 
community more active once it documentation, maybe,  can privilege the 
http://forum.pdpatchrepo.info for example to promote more organized 
collaboration of learning issues between pd community. 

Mensaje telepatico asistido por maquinas.


  
___

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

Re: [PD] multi-language help patches

2016-02-27 Thread Lucas Cordiviola 
Eventually the user can
make his particularly language translated patch:






Or it can be obteined with
some href and an Id, not sure if its posible:



pd_obj...@wikipedia.org













#N canvas 20 43 698 447
12;
#X floatatom 524 338 0 0
0;
#X floatatom 353 338 0 0
0;
#X floatatom 298 338 0 0
0;
#X floatatom 413 338 0 0
0;
#X floatatom 467 338 0 0
0;
#X obj 524 311 <;
#X obj 298 262 r left;
#X obj 540 267 r right;
#X floatatom 71 335 0 0 0;
#X floatatom 19 334 0 0 0;
#X floatatom 119 335 0 0
0;
#X floatatom 163 334 0 0
0;
#X obj 16 45 &;
#X obj 66 45 |;
#X obj 118 45 &&;
#X obj 169 45 ||;
#X obj 19 307 &;
#X obj 71 308 |;
#X obj 119 308 &&;
#X obj 163 307 ||;
#X text 13 73 uoyhbqrevfg
qrepfgvb;
#X obj 19 266 r left;
#X obj 218 266 r right;
#X obj 12 118 >;
#X obj 61 118 >=;
#X obj 114 118 ==;
#X obj 215 119 <=;
#X obj 262 119 <;
#X text 11 153 ouyhqergf
eqwrvgupoyhb;
#X obj 298 312 >;
#X obj 353 312 >=;
#X obj 413 312 ==;
#X obj 467 312 <=;
#X text 16 190
piuqgherfpgiuhqerfg qerpfgiuberpigureg erpiuybqepirugbqerg
qerpiyhbqperiugbqerg qepriyhbqepirgb 

piybqergipub
iuqberifvuhq[iuerhgfv qifvubqe[riuh[uheqrg piubqrguh
;
#X floatatom 410 65 0 0 0;
#X obj 410 92 s left;
#X floatatom 481 66 0 0 0;
#X obj 481 94 t b f;
#X obj 481 122 s left;
#X obj 541 122 s right;
#X obj 166 118 !=;
#X text 377 42 ouyvqdev
qewrpfgvy;
#X floatatom 202 335 0 0
0;
#X floatatom 246 334 0 0
0;
#X obj 208 46 <<;
#X obj 259 46 >>;
#X obj 202 308 <<;
#X obj 246 307 >>;
#X text 421 383
ouyvqwerfhb  version 0.32;
#X connect 5 0 0 0;
#X connect 6 0 29 0;
#X connect 6 0 30 0;
#X connect 6 0 31 0;
#X connect 6 0 32 0;
#X connect 6 0 5 0;
#X connect 7 0 29 1;
#X connect 7 0 30 1;
#X connect 7 0 31 1;
#X connect 7 0 32 1;
#X connect 7 0 5 1;
#X connect 16 0 9 0;
#X connect 17 0 8 0;
#X connect 18 0 10 0;
#X connect 19 0 11 0;
#X connect 21 0 16 0;
#X connect 21 0 17 0;
#X connect 21 0 18 0;
#X connect 21 0 19 0;
#X connect 21 0 46 0;
#X connect 21 0 47 0;
#X connect 22 0 19 1;
#X connect 22 0 18 1;
#X connect 22 0 17 1;
#X connect 22 0 16 1;
#X connect 22 0 47 1;
#X connect 22 0 46 1;
#X connect 29 0 2 0;
#X connect 30 0 1 0;
#X connect 31 0 3 0;
#X connect 32 0 4 0;
#X connect 34 0 35 0;
#X connect 36 0 37 0;
#X connect 37 0 38 0;
#X connect 37 1 39 0;
#X connect 46 0 42 0;
#X connect 47 0 43 0;




Mensaje telepatico asistido por maquinas.

From: emvive...@gmail.com
Date: Sat, 27 Feb 2016 19:19:33 +
Subject: Re: [PD] multi-language help patches
To: lucard...@hotmail.com; pd-list@lists.iem.at


Em sáb, 27 de fev de 2016 15:46, Lucas Cordiviola <lucard...@hotmail.com> 
escreveu:



As an sketch:



pd nameoftheobject
@wikipedia.org



pd osc~ or with the
underscore pd_osc~



https://en.wikipedia.org/wiki/pd_osc~



It will be slow to fill
objects but...







>
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.








Totally agree with that
but perhaps that is just for the international english default  (the
standard default help system). Other languages could be HELPED in
html format.



I`ve also proposed the
translation of just the comments in *-help.pd files, but that seems
difficult and language packs...
I think a comment object with better features yet is a great feature, but the 
weighing the high development cost, this html solution for helps, can do the 
community more active once it documentation, maybe,  can privilege the 
http://forum.pdpatchrepo.info for example to promote more organized 
collaboration of learning issues between pd community. 

Mensaje telepatico asistido por maquinas.


  
___

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

Re: [PD] multi-language help patches

2016-02-27 Thread Esteban Viveros 
Em sáb, 27 de fev de 2016 15:46, Lucas Cordiviola 
escreveu:

> As an sketch:
>
>
> pd nameoftheobject @wikipedia.org
>
>
> pd osc~ or with the underscore pd_osc~
>
>
> https://en.wikipedia.org/wiki/pd_osc~
>
>
> It will be slow to fill objects but...
>
>
>
> > 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.
>
>
>
> Totally agree with that but perhaps that is just for the international
> english default (the standard default help system). Other languages could
> be HELPED in html format.
>
>
> I`ve also proposed the translation of just the comments in *-help.pd
> files, but that seems difficult and language packs...
>

I think a comment object with better features yet is a great feature, but
the weighing the high development cost, this html solution for helps, can
do the community more active once it documentation, maybe,  can privilege
the
http://forum.pdpatchrepo.info for example to promote more organized
collaboration of learning issues between pd community.


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

Re: [PD] multi-language help patches

2016-02-27 Thread 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@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 
> 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  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  wrote:
>
>
> -Jonathan
>
>
> On Friday, February 26, 2016 4:34 PM, Dan Wilcox 
> 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  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,

Re: [PD] multi-language help patches

2016-02-27 Thread Lucas Cordiviola 
Sorry, I didn`t know it lived in the past, never use it.
Could we use wikipedia for that and somehow guarantee longevity, ease of use 
for the community, and multilingual html help files?
Mensaje telepatico asistido por maquinas.

To: pd-list@lists.iem.at
From: zmoel...@iem.at
Date: Sat, 27 Feb 2016 16:38:32 +0100
Subject: Re: [PD] multi-language help patches

On 02/27/2016 03:21 AM, Lucas Cordiviola wrote:
> link which points to http://wiki.puredata.info/en/osc~ that don't exist yet.
 
well, given that pdpedia died a couple of years ago, the "yet" is
slightly euphemistic.
 
gfmards
IOhannes
 
 
 

___
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

Re: [PD] multi-language help patches

2016-02-27 Thread Lucas Cordiviola 
Sorry, I didn`t know it lived in the past, never use it.
Could we use wikipedia for that and somehow guarantee longevity, ease of use 
for the community, and multilingual html help files?
Mensaje telepatico asistido por maquinas.

To: pd-list@lists.iem.at
From: zmoel...@iem.at
Date: Sat, 27 Feb 2016 16:38:32 +0100
Subject: Re: [PD] multi-language help patches

On 02/27/2016 03:21 AM, Lucas Cordiviola wrote:
> link which points to http://wiki.puredata.info/en/osc~ that don't exist yet.
 
well, given that pdpedia died a couple of years ago, the "yet" is
slightly euphemistic.
 
gfmards
IOhannes
 
 
 

___
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

Re: [PD] multi-language help patches

2016-02-27 Thread IOhannes m zmölnig 
On 02/27/2016 03:21 AM, Lucas Cordiviola wrote:
> link which points to http://wiki.puredata.info/en/osc~ that don't exist yet.

well, given that pdpedia died a couple of years ago, the "yet" is
slightly euphemistic.

gfmards
IOhannes





signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] multi-language help patches

2016-02-26 Thread Dan Wilcox 
I’m suggesting that both website docs AND local docs opened in/by Pd can be the 
same html+media.


Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Feb 26, 2016, at 6:09 PM, Lucas Cordiviola <lucard...@hotmail.com> wrote:
> 
> Can it be done with puredata.info <http://puredata.info/>?
> 
> Mensaje telepatico asistido por maquinas.
> 
> From: danomat...@gmail.com
> Date: Fri, 26 Feb 2016 17:35:58 -0700
> To: jancs...@yahoo.com
> CC: pd-list@lists.iem.at
> Subject: Re: [PD] multi-language help patches
> 
> I'd look at how the processing team has put their site/reference together:
> https://github.com/processing/processing-docs 
> <https://github.com/processing/processing-docs>
> 
> It's basically using a php engine with content written and parsed in xml. 
> Each function/class to be documented has it's own file and each file starts 
> form a template which the author then just needs to fill out. I'm not 
> suggesting using xml, etc but I like the layout from an editing & parsing 
> perspective.
> 
> And this is the processing reference, which I feel is a great model for a 
> teaching/arts environment (aka good balance towards readability for beginners 
> and the important info for pros). This section is also included when you 
> download Processing and opened automatically via a link form the Processing 
> IDE itself as well as contextual menu when hilghighting functions & classes 
> in the editor:
> 
> https://processing.org/reference/ <https://processing.org/reference/>
> 
> Openframeworks has been going in that direction, but the codebase is a lot 
> larger and the underlying C++ requires more details to explain, etc hence the 
> recent DocSprint. So far, the examples have been refreshed and lots of useful 
> snippets & longer form tutorials/books have been put together:
> 
> New Learning page from last weekend: http://openframeworks.cc/learning/ 
> <http://openframeworks.cc/learning/>
> Existing reference: http://openframeworks.cc/documentation/ 
> <http://openframeworks.cc/documentation/>
> 
> Here's the current OF website using markdown parsing & generation:
> https://github.com/openframeworks/ofSite 
> <https://github.com/openframeworks/ofSite>
> 
> And here's a new approach to generating the OF documentation as a work in 
> progress:
> https://github.com/halfdanj/ofdocumentationgenerator 
> <https://github.com/halfdanj/ofdocumentationgenerator>
> 
> Here's a couple docs and workflows that have come out of and/or been 
> generated by the DocSprint work:
> 
> https://hackpad.com/API-Documentation-Overview-wCQ4J5hrBbW 
> <https://hackpad.com/API-Documentation-Overview-wCQ4J5hrBbW>
> 
> https://github.com/openframeworks/openFrameworks/wiki/Examples-Contribution-Process-Flow
>  
> <https://github.com/openframeworks/openFrameworks/wiki/Examples-Contribution-Process-Flow>
> 
> 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? However, 
> this would allow for a place for larger scale information as well as images, 
> embed, etc.
> 
> 
> Dan Wilcox
> @danomatika <https://twitter.com/danomatika>
> danomatika.com <http://danomatika.com/>
> robotcowboy.com <http://robotcowboy.com/>
> On Feb 26, 2016, at 5:20 PM, Jonathan Wilkes <jancs...@yahoo.com 
> <mailto:jancs...@yahoo.com>> wrote:
> 
> Do you have a spec from that sprint?
> 
> 
> On Friday, February 26, 2016 7:08 PM, Dan Wilcox <danomat...@gmail.com 
> <mailto: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
&g

Re: [PD] multi-language help patches

2016-02-26 Thread Lucas Cordiviola 
Can it be done with puredata.info?

Mensaje telepatico asistido por maquinas.

From: danomat...@gmail.com
Date: Fri, 26 Feb 2016 17:35:58 -0700
To: jancs...@yahoo.com
CC: pd-list@lists.iem.at
Subject: Re: [PD] multi-language help patches

I'd look at how the processing team has put their site/reference 
together:https://github.com/processing/processing-docs
It's basically using a php engine with content written and parsed in xml. Each 
function/class to be documented has it's own file and each file starts form a 
template which the author then just needs to fill out. I'm not suggesting using 
xml, etc but I like the layout from an editing & parsing perspective.
And this is the processing reference, which I feel is a great model for a 
teaching/arts environment (aka good balance towards readability for beginners 
and the important info for pros). This section is also included when you 
download Processing and opened automatically via a link form the Processing IDE 
itself as well as contextual menu when hilghighting functions & classes in the 
editor:
https://processing.org/reference/
Openframeworks has been going in that direction, but the codebase is a lot 
larger and the underlying C++ requires more details to explain, etc hence the 
recent DocSprint. So far, the examples have been refreshed and lots of useful 
snippets & longer form tutorials/books have been put together:
New Learning page from last weekend: http://openframeworks.cc/learning/Existing 
reference: http://openframeworks.cc/documentation/
Here's the current OF website using markdown parsing & 
generation:https://github.com/openframeworks/ofSite
And here's a new approach to generating the OF documentation as a work in 
progress:https://github.com/halfdanj/ofdocumentationgenerator
Here's a couple docs and workflows that have come out of and/or been generated 
by the DocSprint work:
https://hackpad.com/API-Documentation-Overview-wCQ4J5hrBbW
https://github.com/openframeworks/openFrameworks/wiki/Examples-Contribution-Process-Flow
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? However, this would 
allow for a place for larger scale information as well as images, embed, etc.


Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com



On Feb 26, 2016, at 5:20 PM, Jonathan Wilkes <jancs...@yahoo.com> wrote:Do you 
have a spec from that sprint?

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 wil...@danomatikadanomatika.comrobotcowboy.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

Re: [PD] multi-language help patches

2016-02-26 Thread Jonathan Wilkes via Pd-list 
Do you have a spec from that sprint?

On Friday, February 26, 2016 7:08 PM, Dan Wilcox  
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  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  wrote:

-Jonathan 

On Friday, February 26, 2016 4:34 PM, Dan Wilcox  
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  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  
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 scalable


Sounds like .html.

Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com

___
Pd-list@lists.iem.at mailing list

Re: [PD] multi-language help patches

2016-02-26 Thread Dan Wilcox 
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  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 > > wrote:
>> 
>> 
>> -Jonathan
>> 
>> 
>> On Friday, February 26, 2016 4:34 PM, Dan Wilcox > > 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 >> > 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 >> > 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.

Re: [PD] multi-language help patches

2016-02-26 Thread Lucas Cordiviola 
Are you shure you want to use the wikipedia for that?

Mensaje telepatico asistido por maquinas.

Date: Fri, 26 Feb 2016 23:44:49 +
To: danomat...@gmail.com
CC: pd-list@lists.iem.at
Subject: Re: [PD] multi-language help patches
From: pd-list@lists.iem.at

Ok, so which html reference system should I leverage here?  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? 
-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 wil...@danomatikadanomatika.comrobotcowboy.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 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@danomatikadanomatika.comrobotcowboy.com___pd-l...@lists.iem.at
 mailing listUNSUBSCRIBE 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

Re: [PD] multi-language help patches

2016-02-26 Thread Dan Wilcox 

> 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  wrote:
> 
> 
> -Jonathan
> 
> 
> On Friday, February 26, 2016 4:34 PM, Dan Wilcox  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 > > 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 > > 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

Re: [PD] multi-language help patches

2016-02-26 Thread Jonathan Wilkes via Pd-list 
Ok, so which html reference system should I leverage here?  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? 
-Jonathan 

On Friday, February 26, 2016 4:34 PM, Dan Wilcox  
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  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  
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 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

Re: [PD] multi-language help patches

2016-02-26 Thread 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: danomat...@gmail.com
Date: Fri, 26 Feb 2016 14:33:59 -0700
To: jancs...@yahoo.com
CC: pd-list@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 <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 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 wil...@danomatikadanomatika.comrobotcowboy.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

Re: [PD] multi-language help patches

2016-02-26 Thread Dan Wilcox 
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  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  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

Re: [PD] multi-language help patches

2016-02-26 Thread Jonathan Wilkes via Pd-list 
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  
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 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

Re: [PD] multi-language help patches

2016-02-26 Thread Jonathan Wilkes via Pd-list 
> M-L-Help files can be donetranslating each help file and saving it with a 
> name like“metro-help-ES.pd” or “metro-help-FR.pd” then telling pd toadd 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.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.
  

On Friday, February 26, 2016 2:30 PM, Lucas Cordiviola 
<lucard...@hotmail.com> wrote:
 

 #yiv5077710351 #yiv5077710351 --.yiv5077710351hmmessage 
P{margin:0px;padding:0px;}#yiv5077710351 
body.yiv5077710351hmmessage{font-size:12pt;font-family:Calibri;}#yiv5077710351 
multi-language patch“comments” can be done without any modifications, simply 
usingmore area on the screen or in a sub patch.
Normally you providecomments in your native language and in english.
Mensaje telepatico asistido por maquinas.

From: lucard...@hotmail.com
To: pd-list@lists.iem.at
Date: Fri, 26 Feb 2016 18:46:59 +0000
Subject: Re: [PD] multi-language help patches

#yiv5077710351 #yiv5077710351 --.yiv5077710351ExternalClass 
.yiv5077710351ecxhmmessage P {padding:0px;}#yiv5077710351 
.yiv5077710351ExternalClass body.yiv5077710351ecxhmmessage 
{font-size:12pt;font-family:Calibri;}#yiv5077710351 I think multi-languagepatch 
“comments” is more difficult than multi-language “Helpfiles”.
M-L-Help files can be donetranslating each help file and saving it with a name 
like“metro-help-ES.pd” or “metro-help-FR.pd” then telling pd toadd the -ES or 
-XX to the english helpfile name.
This is a lot of work, butcan/should be done by the community, I remember that 
something likethis has been done in Pd-extended menus with an 
onlineinfrastructure, everyone contributed with what was left to be done.
Of course this increases alot the size of the package, there should be 
something likedownloading only the extra language that you use and not all. 
Somefolder somewhere.
Just a sketch.
Mensaje telepatico asistido por maquinas.

From: danomat...@gmail.com
Date: Fri, 26 Feb 2016 10:59:21 -0700
To: pd-list@lists.iem.at
Subject: Re: [PD] multi-language help patches


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 scalable


Sounds like .html.

Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com

___pd-l...@lists.iem.at mailing 
listUNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list 
___pd-l...@lists.iem.at mailing 
listUNSUBSCRIBE 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

Re: [PD] multi-language help patches

2016-02-26 Thread Lucas Cordiviola 
I think multi-language
patch “comments” is more difficult than multi-language “Help
files”.



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.



This is a lot of work, but
can/should be done by the community, I remember that something like
this has been done in Pd-extended menus with an online
infrastructure, everyone contributed with what was left to be done.



Of course this increases a
lot the size of the package, there should be something like
downloading only the extra language that you use and not all. Some
folder somewhere.



Just a sketch.
Mensaje telepatico asistido por maquinas.

From: danomat...@gmail.com
Date: Fri, 26 Feb 2016 10:59:21 -0700
To: pd-list@lists.iem.at
Subject: Re: [PD] multi-language help patches

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 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

Re: [PD] multi-language help patches

2016-02-26 Thread Dan Wilcox 
> 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