--- On Mon, 8/16/10, João Pais jmmmpais@googlemail.com wrote:
From: João Pais jmmmpais@googlemail.com Subject: Re: [PD] [FM Discuss] Portuguese translation of the PD manual To: "Mathieu Bouchard" matju@artengine.ca Cc: pd-list@iem.at, discuss@lists.flossmanuals.net Date: Monday, August 16, 2010, 1:14 AM
- but anyway Pd's operating
language is (and it will be for much time)
english. Since all help files are in english, it's
not possible to go beyond
a certain level in Pd without coping with this.
Do you mean it's not possible to translate help files
?
I guess it should be as possible as to translate anything else. but since the "official language" is english, and all attached documents are english, don't know how is feasible to translate everything and keep things updated in any other language. unless many people have lots of free time.
Having the object list in english slowly makes
people get used to this
reality
Having the object list translated slowly makes people
get used to the
possible future of translated help files.
guess so. be my guest, I'm not stopping anyone. just don't waste all the time and energy in any uncoordenated effort, leaving in the end lots of scattered information.
- I compiled this object list, and am fed up with
it - it had to
be done with copy-paste.
I have made a tool to maintain an object list in
several languages. It's
what was used to generate gridflow/doc/index.pd.
Currently I use it only
for a single language, but it's already easy to plug
alternate languages
into it, and it sorts the object list alphabetically
and keeps everything
aligned, with the same spacing all over.
Just to make sure : by object list I mean something
with short
descriptions, as found when right-clicking in the
background of a canvas.
You mean the same thing, right ?
yes. http://en.flossmanuals.net/bin/view/PureData/, "LIST OF OBJECTS"
this list is, in theory, already obsolete 5
minutes after being done.
There are always new objects,
I don't think that there ought to be a single
centrally-maintained list.
that was the state of Pd externals before Pd-ext appeared, and no one knew exactly how many and which objects were available. I don't imagine having things scattered around to be of advantage to any users or programmers out there. something similar would logically apply to a general object list, I haven't heard anyone complaining about the effort I've made in making a big (unfinished) list of objects.
I also don't think that it ought to be in a format that
makes you think
something like "it's obsolete 5 minutes after being
done" : a minor update
should feel like a minor update and not like a whole
"oh no, not again !"
kind of chore.
for now the original format is an excel file, hardly a recommendable format for a dynamic list. someone had shown interest in making a drupal online list server, but I haven't heard from him for over an year.
Here's an object list I dynamically created, relying on the PDDP tags that I added to each patch.
http://puredata.info/Members/jwilkes/object-list/view
It makes use of pddp/helplink (although I'm finding that for objects that all share a common help patch, like [cos] and [sin], helplink doesn't work). It's in order of file name, so it's not quite alphabetical.
But rather than a big static list, I'd like to see a nice object search function that can generate a list relevant to the user. (Especially when searching for externals.)
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Here's an object list I dynamically created, relying on the PDDP tags that I added to each patch.
http://puredata.info/Members/jwilkes/object-list/view
It makes use of pddp/helplink (although I'm finding that for objects that all share a common help patch, like [cos] and [sin], helplink doesn't work). It's in order of file name, so it's not quite alphabetical.
But rather than a big static list, I'd like to see a nice object search function that can generate a list relevant to the user. (Especially when searching for externals.)
I'll look at it later. I guess that would be a nice system, but it needs
that the developers also take their part, or allow that someone formats
their patches (or makes them write one in the first place).
If the developers do their part, I think this would be a great system. But
since I'm used that they don't I was thinking myself of a "dynamic"
database which scans the /extra folder. Added items (based on filenames)
would be formatted once, and then fixed. New items would have to be
formated once by hand (copy-paste the description...), but then would
remain in the library. I thought of this because several people don't
follow any guidelines (which don't exist), so it's not possible to trust
the developers to help with that work.
But your system would be much nicer. Maybe would it be possible to make
code submitabble only when there's a help patch with it, or generate these
tags through svn? It's not that much work to add that to the vanilla
objects, it's worth the effort of doing it once - I could help with that,
if St Puckette allows it.
João
(Btw, I still didn't send you my related objects for you to add)
--- On Mon, 8/16/10, João Pais jmmmpais@googlemail.com wrote:
From: João Pais jmmmpais@googlemail.com Subject: Re: Object List (was: Re: [PD] [FM Discuss] Portuguese translation of the PD manual) To: "Mathieu Bouchard" matju@artengine.ca, "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, discuss@lists.flossmanuals.net Date: Monday, August 16, 2010, 12:10 PM
Here's an object list I
dynamically created, relying on the
PDDP tags that I added to each patch.
http://puredata.info/Members/jwilkes/object-list/view
It makes use of pddp/helplink (although I'm finding that for objects
that all
share a common help patch, like [cos] and [sin],
helplink
doesn't work). It's in order of file name, so
it's not quite
alphabetical.
But rather than a big static list, I'd like to see a
nice
object search function that can generate a list
relevant to the
user. (Especially when searching for
externals.)
I'll look at it later. I guess that would be a nice system, but it needs that the developers also take their part, or allow that someone formats their patches (or makes them write one in the first place).
If the developers do their part, I think this would be a great system. But since I'm used that they don't I was thinking myself of a "dynamic" database which scans the /extra folder. Added items (based on filenames) would be formatted once, and then fixed. New items would have to be formated once by hand (copy-paste the description...), but then would remain in the library. I thought of this because several people don't follow any guidelines (which don't exist), so it's not possible to trust the developers to help with that work.
All that's really needed is one rule: new objects must have a help patch to be included in Pd-ext. Once there is a help patch you can get the name of the object from the help patch's file name, and the library from the folder it's in.
Other helpful info to be included would be the following PDDP tags: ALIAS shortname for the object AUTHOR LICENSE KEYWORDS DESCRIPTION (this is probably the most important for searching) RELEASE_DATE
and then inlet info: INLET_0 set bang float INLET_1 float INLET_N (variable number of inlets) INLET_R (rightmost inlet, like pointer inlet on [append])
and the same for outlets.
I put all this in the [pd META] subpatch, but it could easily be put in the main body of the patch.
I think matju's GFDP ends up with a lot of the same info, except for AUTHOR, LICENSE, KEYWORDS, RELEASE_DATE.
-Jonathan
But your system would be much nicer. Maybe would it be possible to make code submitabble only when there's a help patch with it, or generate these tags through svn? It's not that much work to add that to the vanilla objects, it's worth the effort of doing it once - I could help with that, if St Puckette allows it.
I've already added those tags to all the vanilla objects -- that's how I was able to generate the list dynamically. I just need to finish one or two "all_about_" patches and I'll commit everything.
I've also added tags to many of the libraries. I think cyclone and some others are finished but I'm not sure who I need to ask for permission to change these.
João
(Btw, I still didn't send you my related objects for you to add)
-
Jonathan Wilkes -
João Pais