What about multilingual Pd ?
I mean,
http://artengine.ca/desiredata/gallery/speaking_in_tongues.png
What do you think about it?
Credits to:
Georg Holzmann (Deutsch) Ramiro Cosentino (Español) Núria Verges (Català) and me. (Français + code)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
formidable! (pour tout le monde du pdmtl-liste pas des nouvelles)
does it include ÜÖÄüöäßÉéÈèÁáÑñ.. as comments?
some corrections for the german version though: “Sende Message...” should be “Sende Nachricht...” “Tidy Up” should be “Aufräumen”
max
Am 11.12.2005 um 17:58 schrieb Mathieu Bouchard:
What about multilingual Pd ?
I mean,
http://artengine.ca/desiredata/gallery/speaking_in_tongues.png
What do you think about it?
Credits to:
Georg Holzmann (Deutsch) Ramiro Cosentino (Español) Núria Verges (Català) and me. (Français + code)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Hallo, Max Neupert hat gesagt: // Max Neupert wrote:
some corrections for the german version though: ?Sende Message...? should be ?Sende Nachricht...?
Actually I would prefer "Sende Message" even in German, as Message in Pd is more a technical term, which I wouldn't translate. At least when talking about Pd in German, nobody I know says "Nachricht", everyone talks about "messages".
Frank Barknecht _ ______footils.org_ __goto10.org__
Le 11 Décembre 2005 17:36, Frank Barknecht a écrit :
Hallo,
Max Neupert hat gesagt: // Max Neupert wrote:
some corrections for the german version though: ?Sende Message...? should be ?Sende Nachricht...?
Actually I would prefer "Sende Message" even in German, as Message in Pd is more a technical term, which I wouldn't translate. At least when talking about Pd in German, nobody I know says "Nachricht", everyone talks about "messages".
I don't know about German, but maybe "Nachricht" is appropriate, even if everyone is using "messages". It's a matter of deciding if using English terms is a bad habit or necessary because our native languages are too "poor"... In Quebec, because we have a "Charter of the French language", a public service translates computer terms to French and even find new words, like "courriel" for email . Here's the web site: http://granddictionnaire.com/ -- Marc
Am 12.12.2005 um 00:36 schrieb Marc Lavallée:
Max Neupert hat gesagt: // Max Neupert wrote:
some corrections for the german version though: ?Sende Message...? should be ?Sende Nachricht...?
Actually I would prefer "Sende Message" even in German, as Message in Pd is more a technical term, which I wouldn't translate. At least
when talking about Pd in German, nobody I know says "Nachricht", everyone talks about "messages".I don't know about German, but maybe "Nachricht" is appropriate,
even if everyone is using "messages". It's a matter of deciding if using
English terms is a bad habit or necessary because our native languages are too "poor"... In Quebec, because we have a "Charter of the French
language", a public service translates computer terms to French and even find
new words, like "courriel" for email . Here's the web site: http://granddictionnaire.com/ -- Marc
yes, i think it's no excuse to use the english word for something
just because everybody does. since i lived in quebec for almost a
year i became much more aware of this... “Sende Message” is such an
ugly mutant of two languages, just like the one the kids in montreal
speak: ostie franglais.
bonne journée, Max
On Mon, 12 Dec 2005, Max Neupert wrote:
yes, i think it's no excuse to use the english word for something just because everybody does. since i lived in quebec for almost a year i became much more aware of this... "Sende Message" is such an ugly mutant of two languages, just like the one the kids in montreal speak: ostie franglais.
wish desire.tk -lang hostie
------------------8<--------cut-here--------8<------------------ #!/usr/bin/env tclsh # Hostie de câlice de traduction en vrââ québécois sti # Fait par l'ambassadeur du QUÉBEC en hostie toastée des deux bords # $Id: hostie.tcl,v 1.1.2.2 2005/12/02 13:29:03 matju Exp $
say undo "Décalisser" say redo "Repatenter" say edit "Gossage" say select_all "Sélecter Toutte" say font_bomb "Hostie de fonts à marde" say tidy_up "Wiper (avec la Zamboni)" say print "Printer... (su'a printeuse, c't'affaire)" say put "Câlicer quequchose là" say media "Péladeau" say test_audio_and_midi "Bizouner avec les pitons" say quit "Crisser son camp d'icitt"
# Comme un vrai punk sti ------------------8<--------cut-here--------8<------------------
Next week: -lang nb = the newbrunswickese version (t'sais like, why que c'est que le chicken a crossé la street?)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
just my 2cents,
if we make the gui (with the _VERY_ simple english) to multilangual, wouldnt we need to translate the objects too ?
like, if you have in the menu "datei - öffnen", then the object "openpanel" should be "öffnenpanel" ?!
what im after, if the users os is in german, they propably never heard about "file" (datei), so she/he needs object named "machedateiname", lol ?
and i think multilangual gives more problems to ALL, than the user learning a little simple english...
so leave the gui (and objects) in english and just make multilanguage help files, tutorials etc...
but then again, as long as theres english version, i dont really care :)
cheers andre
ps. my mother language is finnish, and i was unable to use a finnish language os...
On Mon, 2005-12-12 at 01:16 -0500, Mathieu Bouchard wrote:
On Mon, 12 Dec 2005, Max Neupert wrote:
yes, i think it's no excuse to use the english word for something just because everybody does. since i lived in quebec for almost a year i became much more aware of this... "Sende Message" is such an ugly mutant of two languages, just like the one the kids in montreal speak: ostie franglais.
wish desire.tk -lang hostie
------------------8<--------cut-here--------8<------------------ #!/usr/bin/env tclsh # Hostie de câlice de traduction en vrââ québécois sti # Fait par l'ambassadeur du QUÉBEC en hostie toastée des deux bords # $Id: hostie.tcl,v 1.1.2.2 2005/12/02 13:29:03 matju Exp $
say undo "Décalisser" say redo "Repatenter" say edit "Gossage" say select_all "Sélecter Toutte" say font_bomb "Hostie de fonts à marde" say tidy_up "Wiper (avec la Zamboni)" say print "Printer... (su'a printeuse, c't'affaire)" say put "Câlicer quequchose là" say media "Péladeau" say test_audio_and_midi "Bizouner avec les pitons" say quit "Crisser son camp d'icitt"
# Comme un vrai punk sti ------------------8<--------cut-here--------8<------------------
Next week: -lang nb = the newbrunswickese version (t'sais like, why que c'est que le chicken a crossé la street?)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 12 Décembre 2005 03:52, Andre Schmidt a écrit :
if we make the gui (with the _VERY_ simple english) to multilangual, wouldnt we need to translate the objects too ?
No. The effort is about software localization, not translation of a programming language.
Translating the objects would require PD to support dialects, like AppleScript did. It would be impractical, because PD's language is graphical and not using a natural language metaphor.
Since Apple is based in the U.S. (THE unilinguistic power), I was not surprised when it dropped support for dialects in AppleScript, although it was working perfectly (I used it for a while). The reason invoked was that most developers were not using this feature, but it doesn't mean it was a completely bad idea...
Menu items like "File", "New", "Open", and GUI objects like "messages", "number", "symbol" and "comment" are easy to translate. Non-gui objects must be named, and most have distinct names or are diminutives, so it would be a bad idea to translate them. Even in English, most object names must be decoded, like "osc~"; those names are not in English, they are in the PD dialect.
and i think multilangual gives more problems to ALL, than the user learning a little simple english...
Localization is common and considered a *good* thing.
ALL can also learn or remember a little bit of their own language to use computers; it's part of the solution to keep and enhance our local cultures. Since I'm French speaking, I prefer "commentaire" to "comment", "symbole" to "symbol", "nombre" to "number", "bascule" to "toggle"...
Using "little simple english" with technology is not enough to deal with complex concepts, and it is an insult to our cultural intelligences. English is a rich language, but it's not mine...
so leave the gui (and objects) in english and just make multilanguage help files, tutorials etc...
PD can be localized, like any other software. It's not a problem, and it's the first step to multilingual documentation.
but then again, as long as theres english version, i dont really care :)
PD will alway support its "lingua franca", don't worry.
ps. my mother language is finnish, and i was unable to use a finnish language os...
That's sad. I visited Finland, and most people were using their computers in Finnish. Welcome to the 21th century.
I read the other comments about this sensible subject; of course, some would prefer to have support for some new "super-duper" features, and consider this language issue irrelevent. The good news is that PD is a free software and therefore open to people that would like to use it in their own language.
Mathieu, we want DesireData! (and a better name...) -- Marc
Marc Lavallée wrote:
Localization is common and considered a *good* thing.
ALL can also learn or remember a little bit of their own language to use computers; it's part of the solution to keep and enhance our local cultures. Since I'm French speaking, I prefer "commentaire" to "comment", "symbole" to "symbol", "nombre" to "number", "bascule" to "toggle"...
Of course localization is a good thing, but let's consider WHY it should be done. If it's a matter of linguistic preference by longtime users, that is well and good and by all means knock yourselves out and have fun doing it! ;-)
But if it's a matter of attracting new users, or supporting users who don't understand English very well (such as about 90% of the Brasillians I workshopped with a month ago), then the docs and the help files need to be (improved and) translated before a localized GUI is going do them much good. In this respect, however, non-English character support would help greatly. Difficult steps, but necessary ones.
d.
Le 12 Décembre 2005 12:50, derek holzer a écrit :
But if it's a matter of attracting new users, or supporting users who don't understand English very well (such as about 90% of the Brasillians I workshopped with a month ago), then the docs and the help files need to be (improved and) translated before a localized GUI is going do them much good.
First contact with a new software is easier in your own language. A translated documentation is even better if the GUI is translated. Also, if the localization of the software happens after the localization of the documentation, then all texts and screenshots would need to be upgraded. If there's support for localized help patches, then obviously support for a localized GUI.
In this respect, however, non-English character support would help greatly. Difficult steps, but necessary ones.
Marc
Marc Lavallée wrote:
First contact with a new software is easier in your own language.
Agreed!
A translated documentation is even better if the GUI is translated.
Also agreed!
Also, if the localization of the software happens after the localization of the documentation, then all texts and screenshots would need to be upgraded.
Here you have the old chicken/egg syndrome. If the GUI says "Nachricht", but the docs say "Message", you have a big problem for a new user, and I would argue that is a bigger problem than if the GUI says "Message", the docs say "Message", but the user happens to be German.
The danger I see is that non-English-speaking users will (of course) be attracted by reading that PD "supports" French, German, Portuguese, whatever. And the initial experience with the GUI will support that, but any further attempts to figure out what is really going on will only frustrate them because the help files and documentation are inconsistant with both the GUI and their expectations that their langauge is "supported".
If there's support for localized help patches, then obviously support for a localized GUI.
Natürlich!
In practical terms, my suggestion would be to would leave localized GUI support in the dev catagory, and not mention it anyplace else until matching documentation is supported. While that doesn't affect Miller's releases at all, it does leave people like Hans-Christoph and other package-maintainers in a position where they must decide if GUI support without documentation to go with it is an appropriate inclusion.
d.
Le 12 Décembre 2005 13:53, derek holzer a écrit :
Here you have the old chicken/egg syndrome. If the GUI says "Nachricht", but the docs say "Message", you have a big problem for a new user, and I would argue that is a bigger problem than if the GUI says "Message", the docs say "Message", but the user happens to be German.
Then it would help to have a menu to choose the language, instead of only use the language of the desktop environment.
The danger I see is that non-English-speaking users will (of course) be attracted by reading that PD "supports" French, German, Portuguese, whatever. And the initial experience with the GUI will support that, but any further attempts to figure out what is really going on will only frustrate them because the help files and documentation are inconsistant with both the GUI and their expectations that their langauge is "supported".
The situation can be explained, and (smart) users can understand. There's tons on software being translated, and it takes time. Frustated users can always stick to English; anyway, the "frustrated" type often decide to live its entire computer life in English, no matter if resources all available in its own language. If we don't even try to offer multilingual support, because some people could possibly complain, then it will never happen.
In practical terms, my suggestion would be to would leave localized GUI support in the dev catagory, and not mention it anyplace else until matching documentation is supported. While that doesn't affect Miller's releases at all, it does leave people like Hans-Christoph and other package-maintainers in a position where they must decide if GUI support without documentation to go with it is an appropriate inclusion.
Leaving the multilingual feature hidden until everything is perfect would kill the effort. Most computer users are able to work in a mixed language environment. There could be a fallback mechanism to display help in French, then English, then Esperanto (for example). If the localization process is made easy, collaborative and incremental, then usually software and documentation gets translated fast enough. Good examples includes popular desktop environments for Gnu based operating systems, and web CMS like Plone.
I know, I know, life would be much easier with one OS, one type of computer, one language, one country, one political system, and the rest, all matching our own personal preferences... but it appears that diversity and tolerance are good and must be encouraged, even by new media artists.
Mathieu wrote:
If Pd is multilingual (and generally customisable) then it will feel more like home. People care more about things that feel like home -- even software.
Marc
On Mon, 12 Dec 2005, Marc Lavalléee wrote:
Then it would help to have a menu to choose the language, instead of only use the language of the desktop environment.
For now there's only a commandline switch given to desire.tk but I intend to provide more options in the long term. Changing the language during runtime is somewhat more difficult but doable if the proper infrastructure is put in place.
Of course, this is made possible by not venerating a venerable standard called Gettext, which is designed for only one language at a time and comes with a 900k almost-plain-text manual that I would only be inclined to read if I were paid to do that.
I know, I know, life would be much easier with one OS, one type of computer, one language, one country, one political system, and the rest, all matching our own personal preferences... but it appears that diversity and tolerance are good and must be encouraged, even by new media artists.
Life would be alot easier if people just realigned their preferences in harmony with the will of the one true political party and did so with enthusiasm. WW2 was triggered by such a will to make life easier. All hail la Fureur!
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Mon, 12 Dec 2005, derek holzer wrote:
Here you have the old chicken/egg syndrome. If the GUI says "Nachricht", but the docs say "Message", you have a big problem for a new user, and I would argue that is a bigger problem than if the GUI says "Message", the docs say "Message", but the user happens to be German.
This is assuming that the software would only display German _or_ English and not both.
The danger I see is that non-English-speaking users will (of course) be attracted by reading that PD "supports" French, German, Portuguese, whatever. And the initial experience with the GUI will support that, but any further attempts to figure out what is really going on will only frustrate them
In practical terms, my suggestion would be to would leave localized GUI support in the dev catagory, and not mention it anyplace else until matching documentation is supported.
Do you mean: you want to give them an already finished product so that they can't get to know that they can participate in the translation even though they might be an ideal workforce for doing so?
Publicity of Pd should not be done like marketing of commercial off-the-shelf products because the development model of community-based free/libre/open-source projects such as Pd is based on work-in-progress and the removal of (most of) the barrier between the users and the developers.
If some users don't want to have anything to do for the community then they deserve to pay big bucks so that they can rent a permission to use a competing piece of software on a limited number of computers.
People who come to the community demanding a certain level of quality without even offering to contribute anything, not even money, don't even deserve to be part of the community. They may use the free software as much as they wish according to clauses of the BSD and/or the GPL, but they don't have to bug us about it. I want to avoid being polluted by the kind of people who think that free software developers are an inferior species of critters that deserve to be exploited.
Because of all of that, I don't think that we have to either support a
language as in provide everything in that language or not do it at all.
If someone is really pissed because N % of the doc isn't yet translated in
French or Farsi or Faroëse then the only compensation i'll send them is a
reality chèque signed by Santa Claus himself.
I want people to know that Pd is not a finished/polished product and most importantly that they can do something about it!! Else I'd rather start a business building a better Pd with a MAX-style business model and sell the software back to you at 242,55 Euro plus tax, but it would be a lot easier to just disappear from the arts scene completely and go work as a full-time actuarial mathematician in an insurance company.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hi Marc, Mathieu,
I think I've been misiniterpreted on two fronts ;-)
Marc Lavallée wrote:
I know, I know, life would be much easier with one OS, one type of computer, one language, one country, one political system, and the rest, all matching our own personal preferences...
To be clear: I totally support any efforts to internationalize PD, GUI, docs, tutorials or whatever. And I certainly don't want to advocate a "wouldn't it be nicer if everyone spoke one language" kind of paradigm. In fact, quite the opposite, I want more people in Brazil, Belgium, Botswana and Bangladesh using PD. And all in their own native languages!
Frustated users can always stick to English;
In some ways this makes my point: that translating only the GUI would merely be a matter of preference or convenience for existing or English-speaking users, and not a workable attempt (yet) to bring the software to non-English speakers.
Mathieu Bouchard wrote:
If some users don't want to have anything to do for the community then they deserve to pay big bucks so that they can rent a permission to use a competing piece of software on a limited number of computers.
This is quite far from what I advocate, and in fact the exact opposite. Shouldn't a software, free or not, be usable whether the user is a developer or not?
What I have found from teaching PD to artists over the last three years is that the merging of the user and the developer communities in this particular case of Free Software often leaves the developers and the "power-users" as a kind of "hacker elite". New users, or casual users who do not actively follow the development of the software, have no idea where to start or to find additional material (tutorials, externals, examples, etc). This is a barrier to more widespread use of the software among (non-programmer) artists. Or do we ONLY want users who are also developers?
In Brazil, for example, not everyone has sufficient knowledge of English to dig into the docs or contact the development community. In Brazil, there is a huge popular movement towards Free Software in general, and many artists and artist collectives moving to Free Software for very ideological reasons as well as pratical ones. There are groups of people translating core softwares, but largely this movement happens in cultural centers on the periphery of the cities, and it all happens in Portuguese. Do we expect them to pay for MAX/MSP because they don't speak any other language than Portuguese, and therefore can't get involved in development? ;-)
I'm sorry to be a stick in the mud about this translation thing. I guess the main difference I have is a user-centered perspective, rather then a developer-centered one. At any rate, I totally support anything that makes PD more usable to a wider audience. That includes proper documentation as well as localized interfaces.
best, d
Le 13 Décembre 2005 06:26, derek holzer a écrit :
Shouldn't a software, free or not, be usable whether the user is a developer or not? ... merging of the user and the developer communities in this particular case of Free Software often leaves the developers and the "power-users" as a kind of "hacker elite". ... This is a barrier to more widespread use of the software among (non-programmer) artists. Or do we ONLY want users who are also developers? ... I guess the main difference I have is a user-centered perspective, rather then a developer-centered one.
The idea is not to merge users and developers communities, or create an elite, or leave users behind, or anything like that. As long as people will consider software literacy (or technology in general) like artists usually do, we'll be in trouble. Honestly, I don't know what is a "user-centered perspective", because I don't believed in restrictive concepts that divides people into clear techno-classes. Technology is a natural extend of our bodies (including our brains), so if we want to live together with technology, we should stop thinking in terms of users vs developers. -- Marc
On Tue, 13 Dec 2005, derek holzer wrote:
This is quite far from what I advocate, and in fact the exact opposite. Shouldn't a software, free or not, be usable whether the user is a developer or not?
How do you define "usable" ?
What I have found from teaching PD to artists over the last three years is that the merging of the user and the developer communities in this particular case of Free Software often leaves the developers and the "power-users" as a kind of "hacker elite".
This is pretty much unavoidable to some extent. At least the barrier is made only by knowledge and not by money...
New users, or casual users who do not actively follow the development of the software, have no idea where to start or to find additional material (tutorials, externals, examples, etc).
That's not a problem with the software itself (I mostly try to take care of the software itself because if I don't do it who will?). Do they know about the Pd portal? are there Pd portals other than the main one that do take care of the educational aspects better than puredata.org ?
This is a barrier to more widespread use of the software among (non-programmer) artists. Or do we ONLY want users who are also developers?
Depends... ideally I'd want the user-developer distinction to be blurred such that it becomes a continuum with a steady ramp up. (Well, that's every teacher's dream, too.)
In Brazil, for example, not everyone has sufficient knowledge of English to dig into the docs or contact the development community. In Brazil, there is a huge popular movement towards Free Software in general,
Then what are you guys/gals waiting for? We have six languages for phase 1 already. That's a first test. I'll come up with a second phase of translation this week, which will cover more ground.
There are groups of people translating core softwares, but largely this movement happens in cultural centers on the periphery of the cities, and it all happens in Portuguese.
So who's doing the translation then? And what language do they want to translate from, if they don't speak English?
Do we expect them to pay for MAX/MSP because they don't speak any other language than Portuguese, and therefore can't get involved in development? ;-)
Surely there are *some* people who can do some translation, right? If not, then I can't do anything. There has to be some kind of English-Português link in some way, be it them, or you, or Nuno.
In any case, I don't see what I'm supposed to be doing with that, how you are going to get Pd to Brasil without any translators and trying hard to avoid creating interest about translation by hiding the fact that it's possible to have Pd in Português.
I'm sorry to be a stick in the mud about this translation thing. I guess the main difference I have is a user-centered perspective, rather then a developer-centered one.
WTF does "user-centered perspective" mean and how does that bring any solutions (or potential avenues for them) instead of just outlining existing problems?
At any rate, I totally support anything that makes PD more usable [...] That includes proper documentation as well as localized interfaces.
If that's not lip-service, then how do you really *support* localization given that you want to hide the localization effort from people who may want (and be able) to contribute just because "not everyone" can do it?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Mon, 12 Dec 2005, Marc Lavalléee wrote:
No. The effort is about software localization, not translation of a programming language.
In the context of PureData, those two things are curiously similar.
Translating the objects would require PD to support dialects, like AppleScript did.
It doesn't, because the .pd files don't need to contain non-english classnames, whereas you'd write AppleScript in a plain text editor with no special translation support from the editor, so AppleScript files _had_ to be themselves multilingual.
It would be impractical, because PD's language is graphical and not using a natural language metaphor.
Pd is hybrid: it's definitely textual to a large extent.
Sign languages are arguably just as natural as the spoken natural languages.
(However, please note that many linguists are conservative and in denial and stuck in a preposterously pre-post-Derrida era where they see writing as speech-like and not speech as writing-like)
Even in English, most object names must be decoded, like "osc~"; those names are not in English, they are in the PD dialect.
Right. vocabulary-wise, Pd is more of a dialect of English than most other programming languages (but less so than NATO +55.(0)242.666)
Using "little simple english" with technology is not enough to deal with complex concepts, and it is an insult to our cultural intelligences.
English is a rich language, but it's not mine...
Vocabulary is only one thing. What distinguishes programming languages from each other has more to do with their grammars, none of which are close to English, even the read-only abortions such as Cobol and AppleScript. (the Smalltalk language is a less naïve attempt at imitating natural language)
I read the other comments about this sensible subject; of course, some would prefer to have support for some new "super-duper" features,
If they prefer it so much, why don't they pay me to do something else??
Mathieu, we want DesireData! (and a better name...)
swap the middle letters: s/red/der/i
does it still look stupid?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Le 12 Décembre 2005 20:54, vous avez écrit :
On Mon, 12 Dec 2005, Marc Lavalléee wrote:
No. The effort is about software localization, not translation of a programming language.
In the context of PureData, those two things are curiously similar.
Even you don't get it? Gee... ;-) http://www.linuxjournal.com/article/6176
Translating the objects would require PD to support dialects, like AppleScript did.
It doesn't, because the .pd files don't need to contain non-english classnames, whereas you'd write AppleScript in a plain text editor with no special translation support from the editor, so AppleScript files _had_ to be themselves multilingual.
Applescript files could be compiled in English and decompiled in French. http://en.wikipedia.org/wiki/AppleScript#AppleScript_dialects
It would be impractical, because PD's language is graphical and not using a natural language metaphor.
Pd is hybrid: it's definitely textual to a large extent.
Appart from the PDPP crew, who's writing their patches using a text editor?
Extreme PD contest: write an electroacoutic and HD video composition for "pd -nogui" using vi. Win the contest and get a lifetime grant to compose a holographic cyber-opera for "pd -sleepgrain 0 -outchannels 1024" and 7 Xbox 360 gamepads using edlin in speech recognition mode. Get famous 50 years after your death from a bad larynx cancer, as a painter (of course), and get all your patches exposed at the Guggenheim (in Bilbao).
(and a better name...)
swap the middle letters: s/red/der/i does it still look stupid?
SidereData?
Marc
On Mon, 12 Dec 2005, Marc Lavallée wrote:
Le 12 Décembre 2005 20:54, vous avez écrit :
On Mon, 12 Dec 2005, Marc Lavalléee wrote:
No. The effort is about software localization, not translation of a programming language.
In the context of PureData, those two things are curiously similar.
Even you don't get it? Gee... ;-) http://www.linuxjournal.com/article/6176
Just because GNU Gettext is considered a standard by many, doesn't mean that I have to use it. There are several reasons not to. And then I still don't "get it", because it's so obvious that you can't even say what it is that "even" I don't get.
Applescript files could be compiled in English and decompiled in French. http://en.wikipedia.org/wiki/AppleScript#AppleScript_dialects
Neat! :)
It would be impractical, because PD's language is graphical and not using a natural language metaphor.
Pd is hybrid: it's definitely textual to a large extent.
Appart from the PDPP crew, who's writing their patches using a text editor?
I'm not saying that, you silly. I'm talking about objectboxes and messageboxes. They contain written code.
Get famous 50 years after your death from a bad larynx cancer, as a painter (of course),
50 years after death? I thought copyright lasted longer than that nowadays...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Dec 12, 2005, at 10:05 AM, Marc Lavallée wrote:
Le 12 Décembre 2005 03:52, Andre Schmidt a écrit :
if we make the gui (with the _VERY_ simple english) to multilangual, wouldnt we need to translate the objects too ?
No. The effort is about software localization, not translation of a programming language.
Translating the objects would require PD to support dialects, like AppleScript did. It would be impractical, because PD's language is graphical and not using a natural language metaphor.
Since Apple is based in the U.S. (THE unilinguistic power), I was not surprised when it dropped support for dialects in AppleScript,
although it was working perfectly (I used it for a while). The reason invoked was
that most developers were not using this feature, but it doesn't mean it
was a completely bad idea...
Maybe the stereotype of the U.S. is unilinguistic, but I know that the
cash machine prompts me to choose between 6 languages, and the ballot
is available in 14 languages, and in typical day, I hear and see
english, spanish, chinese, and arabic, among other languages. Contrary
to popular belief, English is not the "official" language everywhere in
this country. And the law in a number of states requires that people
be given government info in their language, as well as saying that
contracts that are not in a shared language of the involved parties are
not valid.
Just my two bits.
.hc
Menu items like "File", "New", "Open", and GUI objects like "messages", "number", "symbol" and "comment" are easy to translate. Non-gui objects must be named, and most have distinct names or are diminutives, so it
would be a bad idea to translate them. Even in English, most object names
must be decoded, like "osc~"; those names are not in English, they are in the
PD dialect.and i think multilangual gives more problems to ALL, than the user learning a little simple english...
Localization is common and considered a *good* thing.
ALL can also learn or remember a little bit of their own language to
use computers; it's part of the solution to keep and enhance our local cultures. Since I'm French speaking, I prefer "commentaire" to
"comment", "symbole" to "symbol", "nombre" to "number", "bascule" to "toggle"...Using "little simple english" with technology is not enough to deal
with complex concepts, and it is an insult to our cultural intelligences. English is a rich language, but it's not mine...so leave the gui (and objects) in english and just make multilanguage help files, tutorials etc...
PD can be localized, like any other software. It's not a problem, and
it's the first step to multilingual documentation.but then again, as long as theres english version, i dont really care
:)PD will alway support its "lingua franca", don't worry.
ps. my mother language is finnish, and i was unable to use a finnish language os...
That's sad. I visited Finland, and most people were using their computers in
Finnish. Welcome to the 21th century.I read the other comments about this sensible subject; of course, some
would prefer to have support for some new "super-duper" features, and
consider this language issue irrelevent. The good news is that PD is a free
software and therefore open to people that would like to use it in their own language.Mathieu, we want DesireData! (and a better name...) -- Marc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"The arc of history bends towards justice."
- Dr. Martin Luther King, Jr.
On Tue, 13 Dec 2005, Hans-Christoph Steiner wrote:
Maybe the stereotype of the U.S. is unilinguistic, but I know that the cash machine prompts me to choose between 6 languages, and the ballot is available in 14 languages,
Yeah, but in Floridistan, if you vote in another language, they throw your ballot away, so what's the point?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Mon, 12 Dec 2005, Andre Schmidt wrote:
if we make the gui (with the _VERY_ simple english) to multilangual, wouldnt we need to translate the objects too ?
Yes, as well as short descriptions, names of arguments, inlets, methods, outlets. That's before moving on to translating help files.
like, if you have in the menu "datei - öffnen", then the object "openpanel" should be "öffnenpanel" ?!
yes, but will be saved as "openpanel" so that the patch still works in another -lang. Then tooltips can make things bilingual too. It's not like I'm basing my translations on a translation framework that assumes only one language at a time.
what im after, if the users os is in german, they propably never heard about "file" (datei), so she/he needs object named "machedateiname", lol ?
not lol. (apart from the fact that [makefilename] doesn't even do anything filename-specific)
and i think multilangual gives more problems to ALL, than the user learning a little simple english...
How do you substantiate that statement?
so leave the gui (and objects) in english and just make multilanguage help files, tutorials etc...
No.
Putting translation info in help files makes it more difficult for Pd to assist the user more proactively, but also it puts an additional burden of translation on those who make help files, because using a phrase dictionary (like what DesireData does) makes it so that a given phrase only has to be translated once.
but then again, as long as theres english version, i dont really care :)
I'd rather have answers from people who care.
ps. my mother language is finnish, and i was unable to use a finnish language os...
Most brands of Linux install translations in about forty-twelve languages without asking your permission. For many programs this includes Finnish.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
hi all
maybe I'm wrong, but translating the objects names looks quite weird to me. why not consider them as commands in a programming language (which are quite often in english, and everybody looks happy with this) ?
I think it's better, for exemple for international meetings, workshop, to have similar words for a "message" or even for "makefilename", to call stuff and share such knowledge.
do you imagine dealing with stuff like "I got a problem using "créerunnomdefichier"
or "you should copy-paste your console output.
objet créerunnomdefichier ... n'a pas pu créer.
I agree with translating comments in help patches and stuff like that, but translating object names (which are actually keywords) in my opinion would really be annoying for the community.
+++++ clemos
On 12/13/05, Mathieu Bouchard matju@artengine.ca wrote:
On Mon, 12 Dec 2005, Andre Schmidt wrote:
if we make the gui (with the _VERY_ simple english) to multilangual, wouldnt we need to translate the objects too ?
Yes, as well as short descriptions, names of arguments, inlets, methods, outlets. That's before moving on to translating help files.
like, if you have in the menu "datei - öffnen", then the object "openpanel" should be "öffnenpanel" ?!
yes, but will be saved as "openpanel" so that the patch still works in another -lang. Then tooltips can make things bilingual too. It's not like I'm basing my translations on a translation framework that assumes only one language at a time.
what im after, if the users os is in german, they propably never heard about "file" (datei), so she/he needs object named "machedateiname", lol ?
not lol. (apart from the fact that [makefilename] doesn't even do anything filename-specific)
and i think multilangual gives more problems to ALL, than the user learning a little simple english...
How do you substantiate that statement?
so leave the gui (and objects) in english and just make multilanguage help files, tutorials etc...
No.
Putting translation info in help files makes it more difficult for Pd to assist the user more proactively, but also it puts an additional burden of translation on those who make help files, because using a phrase dictionary (like what DesireData does) makes it so that a given phrase only has to be translated once.
but then again, as long as theres english version, i dont really care :)
I'd rather have answers from people who care.
ps. my mother language is finnish, and i was unable to use a finnish language os...
Most brands of Linux install translations in about forty-twelve languages without asking your permission. For many programs this includes Finnish.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 12 Décembre 2005 19:18, clemos a écrit :
hi all
maybe I'm wrong, but translating the objects names looks quite weird to me. why not consider them as commands in a programming language (which are quite often in english, and everybody looks happy with this) ?
That's what I tried to explain in my last message. But it's not a matter of being happy with names and acronyms based on "little small english". Named objects (created by typing in a object box) should not be translated, because they have names... But GUI objects, menu items, console messages and probably other details can be translated.
The goal is not to turn PD into some sort of multi-cultural gorgon, ready to annihilate all anglos in the universe. In order to understand the idea, run some applications in "foreign" languages, and you'll notice that not everything is translated. For the ultimate experience, compile a C++ software using Chinese locales... Then relax and repeat 3 times: "Portez ce vieux whisky au juge blond qui fume." -- Marc
On Tue, 13 Dec 2005, clemos wrote:
do you imagine dealing with stuff like "I got a problem using "créerunnomdefichier"
- do you mean : "machedateiname"?
- oh yeah I mean : "makefilename"! "
Either the original name would be available as a tooltip, or the translated name would be available as a tooltip, depending on translation settings.
"you should copy-paste your console output.
- ok, it's here :
objet créerunnomdefichier ... n'a pas pu créer.
- wtf !!!???"
Can't do anything about that... people routinely post GCC error messages in German and French on public forums and keep on using localized GCC no matter what.
I agree with translating comments in help patches and stuff like that, but translating object names (which are actually keywords) in my opinion would really be annoying for the community.
It depends on how it is handled.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
LOL
Am 12.12.2005 um 07:16 schrieb Mathieu Bouchard:
On Mon, 12 Dec 2005, Max Neupert wrote:
yes, i think it's no excuse to use the english word for something
just because everybody does. since i lived in quebec for almost a year i became
much more aware of this... "Sende Message" is such an ugly mutant of two
languages, just like the one the kids in montreal speak: ostie franglais.wish desire.tk -lang hostie
------------------8<--------cut-here--------8<------------------ #!/usr/bin/env tclsh # Hostie de câlice de traduction en vrââ québécois sti # Fait par l'ambassadeur du QUÉBEC en hostie toastée des deux bords # $Id: hostie.tcl,v 1.1.2.2 2005/12/02 13:29:03 matju Exp $
say undo "Décalisser" say redo "Repatenter" say edit "Gossage" say select_all "Sélecter Toutte" say font_bomb "Hostie de fonts à marde" say tidy_up "Wiper (avec la Zamboni)" say print "Printer... (su'a printeuse, c't'affaire)" say put "Câlicer quequchose là" say media "Péladeau" say test_audio_and_midi "Bizouner avec les pitons" say quit "Crisser son camp d'icitt"
# Comme un vrai punk sti ------------------8<--------cut-here--------8<------------------
Next week: -lang nb = the newbrunswickese version (t'sais like, why
que c'est que le chicken a crossé la street?)_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Mon, 12 Dec 2005, Mathieu Bouchard wrote:
Next week: -lang nb = the newbrunswickese version (t'sais like, why que c'est que le chicken a crossé la street?)
Btw, ironically, a translation called "nb" unsuspectingly crept to me today, but it's not newbrunswickese.
Thanks to Gisle Frøysland for translations to Norsk Bokmål.
And then tonight I got Português ("pt") from Nuno Godinho.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sun, 11 Dec 2005, Max Neupert wrote:
formidable! (pour tout le monde du pdmtl-liste pas des nouvelles) does it include ÜÖÄüöäßÉéÈèÁáÑñ.. as comments?
DesireData has already supported iso-latin-1 for a while, thanks to Chun Lee. However, the program is still waaay too buggy to be usable.
some corrections for the german version though: "Sende Message..." should be "Sende Nachricht..."
I added it as a comment in deutsch.tcl, for further consideration.
However, I think that send_message will disappear soon, or mutate into something else. For several months, DesireData has had both a PdBox and a TclBox, http://artengine.ca/desiredata/gallery/desiredata_1.png, both of which can be made multiline too, by clicking on the "+" button.
One possible nice addition would be to have those boxes embeddable in every patcher window, which would prepend the canvas's receive-sym to each message, so that typing "obj 0 0 adc~" would add an object to the patcher it's been typed in. (think of pd as a commandline tool...)
"Tidy Up" should be "Aufräumen"
changed. (will upload the changes soon)
btw, the format of the translation files is really like I put it in a previous message:
http://cvs.sourceforge.net/viewcvs.py/pure-data/pd/src/locale/Attic/deutsch....
So anyone with a pd developer account can go edit the translation themselves, which ideally would be best so that I don't have to put them in myself, but as it is, half of the translators don't have an account.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada