Hallo, Urs Liska hat gesagt: // Urs Liska wrote:
It's the same with books on programming languages. I am always frustrated with books that translate the technical terms (for example 'member' (of a class) to 'Mitglied') because I basically have to re-translate it to know what it means...
Off-topic: The german version of the SICP book even translated the example program texts - like "(sende-nachricht 1 2)" -, which in LISP is actually possible and could make sense, however I think, it still stinks. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 12 Dec 2005, Frank Barknecht wrote:
Hallo, Urs Liska hat gesagt: // Urs Liska wrote:
It's the same with books on programming languages. I am always frustrated with books that translate the technical terms (for example 'member' (of a class) to 'Mitglied') because I basically have to re-translate it to know what it means...
Off-topic: The german version of the SICP book even translated the example program texts - like "(sende-nachricht 1 2)" -, which in LISP is actually possible and could make sense, however I think, it still stinks. ;)
für German, it makes more sense to use the Reverse Polish Notation (RPN) as commonly used in Forth, PostScript, and HP calculators. e.g.:
1 2 sende-nachricht
but if in English RPN you do, Yoda you will sound like.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
fÃŒr German, it makes more sense to use the Reverse Polish Notation (RPN) as commonly used in Forth, PostScript, and HP calculators. e.g.:
1 2 sende-nachricht
but if in English RPN you do, Yoda you will sound like.
However: German is not RPN, the word order in a sentence is very similar to the one in English and not similar to Yoda. (Maybe it's this way in, uhm, Polish?)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
However: German is not RPN, the word order in a sentence is very similar to the one in English and not similar to Yoda. (Maybe it's this way in, uhm, Polish?)
No, it's not ;-) AFAIK, RPN was developed for mathematical expressions only.
BTW, I don't think pd needs international localization in the current development state. There are many another issues (stability, transparency, documentation) which should get higher priority than localization if pd wants to reach for more users.
br, Piotr
Howdy,
Piotr Majdak wrote:
BTW, I don't think pd needs international localization in the current development state. There are many another issues (stability, transparency, documentation) which should get higher priority than localization if pd wants to reach for more users.
I agree on the level that if you translate the GUI, and even change the names of basic functions (i.e. "message" to "Nachricht"), you will only have a lot of very frustrated non-English-speaking users if the docs aren't also translated. So I would also vote for improved documentation as a focus over localization if PD wants more users.
By this I mean first and foremost more helpful help files (i.e. all features clearly documented), then tutorials which are comprehensible to non-mathematicians and non-programmers, then high-level abstractions which can be easily taken apart and understood and finally translations of all this documentation into major languages. At that point, localization to support translated documentation could be implemented.
I can see that translating the GUI is a much simpler task than doing everything else I just mentioned first, but I'm not convinced that localization is the proper first step.
best, d.
derek holzer wrote:
By this I mean first and foremost more helpful help files (i.e. all features clearly documented), then tutorials which are comprehensible to non-mathematicians and non-programmers, then high-level abstractions which can be easily taken apart and understood and finally translations of all this documentation into major languages. At that point, localization to support translated documentation could be implemented.
:)
Will you be attending the PDDP meeting tomorrow Derek?
Thanks for the vote of support.
B. Bogart wrote:
Will you be attending the PDDP meeting tomorrow Derek?
I'll try. I'm packing house and getting ready to be on the road for about 6 months, so things are a little tight now...
Thanks for the vote of support.
NP. Glad my 2 bits are worth something to someone around here ;-) best, d.
On Mon, 12 Dec 2005, derek holzer wrote:
I agree on the level that if you translate the GUI, and even change the names of basic functions (i.e. "message" to "Nachricht"), you will only have a lot of very frustrated non-English-speaking users if the docs aren't also translated. So I would also vote for improved documentation as a focus over localization if PD wants more users.
Not if the software allows multiple languages at once. Don't assume that my implementation of locali[sz]ation will be what ordinary apps normally do with localisa[tc]i[oó]n.
I can see that translating the GUI is a much simpler task than doing everything else I just mentioned first,
Which is why I did that first and early - because it's easy to do and it gives peoples ideas and inspiration.
but I'm not convinced that localization is the proper first step.
Sequential steps only makes sense when you have a single-thread program executing them. Humans have other efficiency factors, moreso when money is not involved (pd) and moreso when there's a community of people with wildly varying skillsets.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
cześć Piotr,
Piotr Majdak wrote:
Frank Barknecht wrote:
However: German is not RPN, the word order in a sentence is very similar to the one in English and not similar to Yoda. (Maybe it's this way in, uhm, Polish?)
No, it's not ;-) AFAIK, RPN was developed for mathematical expressions
to prawda... jednakże ja to między bajki włożę
Krzysztof
Czesc Krzysztof,
Krzysztof Czaja wrote:
Piotr Majdak wrote:
No, it's not ;-) AFAIK, RPN was developed for mathematical expressions
to prawda... jednak¿e ja to miêdzy bajki w³o¿ê
Kolysanki? :-)
BTW, http://en.wikipedia.org/wiki/Reverse_Polish_Notation
Pozdrowienia z Wiednia,
Piotr
Piotr Majdak wrote: ...
to prawda... jednakże ja to między bajki włożę
Kolysanki? :-)
that was bishop Krasicki's quote, an example of a valid Polish RPN (usually an archaism), and a cute variation on an ancient theme, the ``liar paradox''.
Krzysztof
On Mon, 12 Dec 2005, Krzysztof Czaja wrote:
that was bishop Krasicki's quote, an example of a valid Polish RPN (usually an archaism), and a cute variation on an ancient theme, the ``liar paradox''.
additionally, lots of ancient French poetry ("early-modern", 1500's, and possibly pre-modern too) have lots of RPN-style inversions. When caricaturing poetry, using various word permutations is a classic: as early as 1670, a theatre play makes fun of word permutation poetry («Le Bourgeois Gentilhomme» by Molière).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Am 12.12.2005 um 11:26 schrieb Piotr Majdak:
Frank Barknecht wrote:
However: German is not RPN, the word order in a sentence is very similar to the one in English and not similar to Yoda. (Maybe it's this way in, uhm, Polish?)
No, it's not ;-) AFAIK, RPN was developed for mathematical
expressions only.BTW, I don't think pd needs international localization in the
current development state. There are many another issues
(stability, transparency, documentation) which should get higher
priority than localization if pd wants to reach for more users.
I kind of agree. but on the other hand it really sucks to make non
english tutorials/workshops since the comments don't accept other
than english chars.
max
Max Neupert wrote:
I kind of agree. but on the other hand it really sucks to make non
english tutorials/workshops since the comments don't accept other than english chars.
the good thing about german umlauts is, that you can write them in their alternative forms: À == ae
apart from that, i think that there is a distinction between i18n (translating the software) and allowing non-ascii characters.
UTF-8 would be nice (if it worked!)
mfg.adsr. IOhannes
PS: might be that i am mixing up names like "i18n" and the like, but i hope you get what i mean.
apart from that, i think that there is a distinction between i18n (translating the software) and allowing non-ascii characters.
UTF-8 would be nice (if it worked!)
what do you mean exactly by "if it worked" ?
i am not sure this is a related issue but tcl/tk does not allow displaying unicode characters by default on macosx platforms. However there is a workaround for mac which works with tcl/tk8.4.9 (at least):
[from MACTCL mailing list]:
Unicode doesn't work satifactorily with the QuickDraw API used in the current Tk source. I wrote a patch for using ATSU instead, see http://sourceforge.net/tracker/?group_id=12997&atid=312997&func=detail&aid= 638966. This implementation is slower than the QuickDraw based stuff in some situations, so I am working on optimizations, before this can go into CVS. Unfortunately, optimizing and testing is going slow and I can only devote limited time to it. benny.
For my part, i would be quite satisfied if one could just write/save comments in pd patches in utf8 or latin1 encodings.
greetings, vincent
vincent rioux wrote:
apart from that, i think that there is a distinction between i18n (translating the software) and allowing non-ascii characters.
UTF-8 would be nice (if it worked!)
what do you mean exactly by "if it worked" ?
that UTF-8 gives problems everywhere. most terminal-based applications have no real support for utf-8; most editors do not like it either (try vi[m], try [x]emacs); even my beloved zope/plone has hard times so this would make editing pd-patches via a text-editor unusable (but of course this is a problem with the editors, not with pd)
i really love utf (far better than iso-8859 and the like), but outside OpenOffice it is still often unusable (at least on linux; i recon that w32 works fine with utf8 and osX might do as well)
mfg.asdr. IOhannes
apart from that, i think that there is a distinction between i18n (translating the software) and allowing non-ascii characters.
UTF-8 would be nice (if it worked!)
what do you mean exactly by "if it worked" ?
that UTF-8 gives problems everywhere. most terminal-based applications have no real support for utf-8; most editors do not like it either (try vi[m], try [x]emacs); even my beloved zope/plone has hard times so this would make editing pd-patches via a text-editor unusable (but of course this is a problem with the editors, not with pd)
i really love utf (far better than iso-8859 and the like), but outside OpenOffice it is still often unusable (at least on linux; i recon that w32 works fine with utf8 and osX might do as well)
mfg.asdr. IOhannes
ok, then i totally agree with you, the tricky part being /can unicode strings be integrated into a .pd (text file) relatively simply even if not directly editable with usual text editors? / after all, unicode characters can be represented by escape codes (ascii characters preceded by ), isnt' it?
by the way i would be interested to know how many people are editing their patchs without the patch/cord gui and for what reasons? for my part, i do it very seldom, only when i need to correct a patch that cannot be opened any more.
vincent
On Tue, 13 Dec 2005, vincent rioux wrote:
i really love utf (far better than iso-8859 and the like), but outside OpenOffice it is still often unusable (at least on linux; i recon that w32 works fine with utf8 and osX might do as well)
mfg.asdr. IOhannes
ok, then i totally agree with you, the tricky part being /can unicode strings be integrated into a .pd (text file) relatively simply even if not directly editable with usual text editors? / after all, unicode characters can be represented by escape codes (ascii characters preceded by ), isnt' it?
by the way i would be interested to know how many people are editing their patchs without the patch/cord gui and for what reasons? for my part, i do it very seldom, only when i need to correct a patch that cannot be opened any more.
An easy thing that one can do is replacing the "isprint(n)" by "n > 31" in g_rtext.c and then recompile pd. On linux this produces extended ascii characters. Don' t know what it does on windows and OSX, maybe someone is willing to try.
Günter
vincent
On Dec 13, 2005, at 10:53 AM, geiger wrote:
On Tue, 13 Dec 2005, vincent rioux wrote:
i really love utf (far better than iso-8859 and the like), but
outside OpenOffice it is still often unusable (at least on linux; i recon
that w32 works fine with utf8 and osX might do as well)mfg.asdr. IOhannes
ok, then i totally agree with you, the tricky part being /can unicode strings be integrated into a .pd (text file) relatively simply even if not directly editable with usual text editors? / after all, unicode characters can be represented by escape codes
(ascii characters preceded by ), isnt' it?by the way i would be interested to know how many people are editing their patchs without the patch/cord gui and for what reasons? for my part, i do it very seldom, only when i need to correct a patch that cannot be opened any more.
An easy thing that one can do is replacing the "isprint(n)" by "n > 31" in g_rtext.c and then recompile pd. On linux this produces extended ascii characters. Don' t know what it does on windows and OSX, maybe someone is willing
to try.
Works for me on Mac OS X! Could this simple patch cause any bugs? Why
was isprint() there in the first place?
.hc ________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
On Dec 13, 2005, at 10:37 PM, Hans-Christoph Steiner wrote:
On Dec 13, 2005, at 10:53 AM, geiger wrote:
On Tue, 13 Dec 2005, vincent rioux wrote:
i really love utf (far better than iso-8859 and the like), but
outside OpenOffice it is still often unusable (at least on linux; i recon
that w32 works fine with utf8 and osX might do as well)mfg.asdr. IOhannes
ok, then i totally agree with you, the tricky part being /can unicode strings be integrated into a .pd (text file) relatively simply even if not directly editable with usual text editors? / after all, unicode characters can be represented by escape codes
(ascii characters preceded by ), isnt' it?by the way i would be interested to know how many people are editing their patchs without the patch/cord gui and for what reasons? for my part, i do it very seldom, only when i need to correct a patch that cannot be opened any more.
An easy thing that one can do is replacing the "isprint(n)" by "n > 31" in g_rtext.c and then recompile pd. On linux this
produces extended ascii characters. Don' t know what it does on windows and OSX, maybe someone is willing
to try.Works for me on Mac OS X! Could this simple patch cause any bugs?
Why was isprint() there in the first place?
So far no crashes, tho once I typed a character and it hung for a few
seconds, and then recovered and typed an empty box. Hmm
Here's a little snapshop of the test:
http://eds.org/~hans/Pu%cc%88reDa%cc%88ta%cc%88.pdf
Comments work fine, you can type special characters into object boxes,
but you can't load objects or abstractions using special characters.
And [print] replaces them with a ?.
I am going to include this in the next Pd-extended, we'll see then what
the problems are.
.hc
"I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits."
- Martin Luther King, Jr.
On Tue, 13 Dec 2005, Hans-Christoph Steiner wrote:
So far no crashes, tho once I typed a character and it hung for a few seconds, and then recovered and typed an empty box. Hmm
Font-loading sometimes takes time, especially japanese/chinese/korean fonts, but also unicode fonts, and antialiased fonts.
Comments work fine, you can type special characters into object boxes, but you can't load objects or abstractions using special characters.
There might be a mismatch of charsets. What's the charset of your filesystem?
And [print] replaces them with a ?.
That's one kind of mismatch of charsets: the one you use in pd is most likely utf-8, and the one you use in the Terminal is most likely iso-8859-1 (Latin1) or ascii-7. I usually have to change it the other way around, because I SSH from Unicode-configured Macs into a linux server configured as Latin1.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Dec 14, 2005, at 6:43 AM, Mathieu Bouchard wrote:
On Tue, 13 Dec 2005, Hans-Christoph Steiner wrote:
So far no crashes, tho once I typed a character and it hung for a few seconds, and then recovered and typed an empty box. Hmm
Font-loading sometimes takes time, especially japanese/chinese/korean fonts, but also unicode fonts, and antialiased fonts.
Comments work fine, you can type special characters into object boxes, but you can't load objects or abstractions using special characters.
There might be a mismatch of charsets. What's the charset of your filesystem?
Mac OS X = UTF-8
And [print] replaces them with a ?.
That's one kind of mismatch of charsets: the one you use in pd is most likely utf-8, and the one you use in the Terminal is most likely iso-8859-1 (Latin1) or ascii-7. I usually have to change it the other
way around, because I SSH from Unicode-configured Macs into a linux server configured as Latin1.
Yup, and endless annoyance.
.hc ________________________________________________________________________ ____
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
Hans-Christoph Steiner wrote:
On Dec 13, 2005, at 10:37 PM, Hans-Christoph Steiner wrote:
On Dec 13, 2005, at 10:53 AM, geiger wrote:
On Tue, 13 Dec 2005, vincent rioux wrote:
i really love utf (far better than iso-8859 and the like), but
outside OpenOffice it is still often unusable (at least on linux; i recon
that w32 works fine with utf8 and osX might do as well)mfg.asdr. IOhannes
ok, then i totally agree with you, the tricky part being /can unicode strings be integrated into a .pd (text file) relatively simply even if not directly editable with usual text editors? / after all, unicode characters can be represented by escape codes
(ascii characters preceded by ), isnt' it?by the way i would be interested to know how many people are editing their patchs without the patch/cord gui and for what reasons? for my part, i do it very seldom, only when i need to correct a patch that cannot be opened any more.
An easy thing that one can do is replacing the "isprint(n)" by "n > 31" in g_rtext.c and then recompile pd. On linux this
produces extended ascii characters. Don' t know what it does on windows and OSX, maybe someone is willing to try.Works for me on Mac OS X! Could this simple patch cause any bugs?
Why was isprint() there in the first place?So far no crashes, tho once I typed a character and it hung for a few
seconds, and then recovered and typed an empty box. HmmHere's a little snapshop of the test:
http://eds.org/~hans/Pu%cc%88reDa%cc%88ta%cc%88.pdf
Comments work fine, you can type special characters into object boxes, but you can't load objects or abstractions using special characters. And [print] replaces them with a ?.
I am going to include this in the next Pd-extended, we'll see then what the problems are.
.hc
impressive! one pb i can see is that you might not be able to reproduce it on linux or windows just as well and that it is definetely better to write "espanol", or "francais" when things like "espa?ol" or "fran?ais" (or worse) might come up when you swap platforms.
anyway, this is already a very nice result.
Also, we don't really need to call files (abstractions, libraries, objects) with special characters, this will never really work cross-platform i believe. i sometimes think that a subset of english could work just as unicode does, the difference being that we will never have to learn unicode... or?
vincent
An easy thing that one can do is replacing the "isprint(n)" by "n > 31" in g_rtext.c and then recompile pd. On linux this
produces extended ascii characters. Don' t know what it does on windows and OSX, maybe someone is
willing to try.Works for me on Mac OS X! Could this simple patch cause any
bugs? Why was isprint() there in the first place?So far no crashes, tho once I typed a character and it hung for a
few seconds, and then recovered and typed an empty box. HmmHere's a little snapshop of the test:
http://eds.org/~hans/Pu%cc%88reDa%cc%88ta%cc%88.pdf
Comments work fine, you can type special characters into object
boxes, but you can't load objects or abstractions using special
characters. And [print] replaces them with a ?.I am going to include this in the next Pd-extended, we'll see then
what the problems are.
can hardly wait for it. comments in extended ascii are a big first
step.
On Tue, 13 Dec 2005, Hans-Christoph Steiner wrote:
On Dec 13, 2005, at 10:53 AM, geiger wrote:
An easy thing that one can do is replacing the "isprint(n)" by "n > 31" in g_rtext.c and then recompile pd. On linux this produces extended ascii characters. Don' t know what it does on windows and OSX, maybe someone is willing to try. Works for me on Mac OS X! Could this simple patch cause any bugs? Why was
isprint() there in the first place?
isprint is supposed to be a localized function (man 3 isprint) and by default corresponds to
n>=32 && n<=126
which corresponds to all of the ascii-7 charset codes (used by the "C"
locale).
However, is it possible that Tcl implements UTF-8 regardless of the charset selected by environment variables?
And is it possible that charsets that use wide characters are treated much differently by isprint and such?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Dec 14, 2005, at 6:49 AM, Mathieu Bouchard wrote:
On Tue, 13 Dec 2005, Hans-Christoph Steiner wrote:
On Dec 13, 2005, at 10:53 AM, geiger wrote:
An easy thing that one can do is replacing the "isprint(n)" by "n > 31" in g_rtext.c and then recompile pd. On linux this produces extended ascii characters. Don' t know what it does on windows and OSX, maybe someone is willing to try. Works for me on Mac OS X! Could this simple patch cause any bugs?
Why wasisprint() there in the first place?
isprint is supposed to be a localized function (man 3 isprint) and by default corresponds to
n>=32 && n<=126
which corresponds to all of the ascii-7 charset codes (used by the "C" locale).
However, is it possible that Tcl implements UTF-8 regardless of the charset selected by environment variables?
And is it possible that charsets that use wide characters are treated much differently by isprint and such?
Yes. iswprint() is for that.
.hc
http://at.or.at/hans/
Le 13 Décembre 2005 07:30, IOhannes m zmoelnig a écrit :
so this would make editing pd-patches via a text-editor unusable (but of course this is a problem with the editors, not with pd)
Wow! People really are editing PD patches using text editors. That must be a lot of fun.
i really love utf (far better than iso-8859 and the like), but outside OpenOffice it is still often unusable (at least on linux; i recon that w32 works fine with utf8 and osX might do as well)
There's a lot of good editors that works with UTF-8, and there will be more. Anyway, UTF-8 is compatible with plain old ASCII. (man utf-8) -- Marc
Hi!
Max Neupert wrote:
I kind of agree. but on the other hand it really sucks to make non
english tutorials/workshops since the comments don't accept other than english chars.
Yes, it's very difficult to explain new pd-users why the character set of my Commodore 64 was bigger than in pd ;-)
I think this part of pd is very, very out-of-date and pd should support blanks, backslashes, (please!) escape codes and other chars than english. I know that this issue was very often discussed here and I know there is a solution for that. Could a developer comment this? Should we vote for that?
br, Piotr
Hi all,
I kind of agree. but on the other hand it really sucks to make non
english tutorials/workshops since the comments don't accept other
than english chars.Yes, it's very difficult to explain new pd-users why the character set
of my Commodore 64 was bigger than in pd ;-)I think this part of pd is very, very out-of-date and pd should
support blanks, backslashes, (please!) escape codes and other chars
than english. I know that this issue was very often discussed here and
I know there is a solution for that. Could a developer comment this?
Should we vote for that?
in the discussion about that on the list some months ago - hard to
believe - some people insisted that escaping etc. is not needed. My
opinion is the opposite.
I believe it's quite some work to include these features, alongside
with problems coming from the PD-TCL communication ( see the open bug
report
http://sourceforge.net/tracker/index.php?
func=detail&aid=1359216&group_id=55736&atid=478070 ).
For me personally this is not a problem, because i rely on the devel
branch where DesireData will take these things into account.
best greetings, Thomas
On Mon, 12 Dec 2005, Piotr Majdak wrote:
Max Neupert wrote:
I kind of agree. but on the other hand it really sucks to make non english tutorials/workshops since the comments don't accept other than english chars.
Yes, it's very difficult to explain new pd-users why the character set of my Commodore 64 was bigger than in pd ;-)
The charset of APL was bigger than the one of almost all programming languages, and I tell you, it was APL that people were complaining about!
(However, it was because so many glyphs were given special purposes already, and was eating up the upper half of the 8-bit range, while almost none of them had to do with locali[sz]ation)
I think this part of pd is very, very out-of-date and pd should support blanks, backslashes, (please!) escape codes and other chars than english.
Agreed. It's part of my big plan, but it seems that I never have enough energy to devote to the cause. It's a hard thing to do and one important step is to switch from the current communication system called "sys_vgui", to a more high-level and assisted mechanism which knows personally about PureData types and Tcl syntax and how to translate that. (Tcl is a language used by the user interface in Pd)
I know that this issue was very often discussed here and I know there is a solution for that. Could a developer comment this? Should we vote for that?
A voting system has been alluded to on pd-dev in light of recent issues, but has not been implemented, nor even adequately discussed. I don't think that the restrictions to {} will be resolved pd-wide, except in DesireData, because the fix will cover too much source area, which will fuel complaints by the merge-managers in case Miller doesn't think the fix is to his taste but doesn't want to produce a fix that suits him (that scenario isn't far-fetched and is the current everyday reality of Pd).
_ _ __ ___ _____ ________ _____________ _____________________ ... | 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:44 AM, Piotr Majdak wrote:
Hi!
Max Neupert wrote:
I kind of agree. but on the other hand it really sucks to make non
english tutorials/workshops since the comments don't accept other
than english chars.Yes, it's very difficult to explain new pd-users why the character set
of my Commodore 64 was bigger than in pd ;-)I think this part of pd is very, very out-of-date and pd should
support blanks, backslashes, (please!) escape codes and other chars
than english. I know that this issue was very often discussed here and
I know there is a solution for that. Could a developer comment this?
Should we vote for that?
If you want it to happen, pay someone to do it. Then it'll happen. I
don't think anyone is opposed to having this in Pd, just no one has the
time to do it.
.hc
br, Piotr
--
Piotr Majdak Institut für Schallforschung Österreichische Akademie der Wissenschaften Reichsratsstr. 17 A-1010 Wien Tel.: +43-1-4277-29511 Fax: +43-1-4277-9296 E-Mail: piotr@majdak.com WWW: http://www.kfs.oeaw.ac.at
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to
realize his wishes.
Now that he can realize them, he must either change them, or perish.
-William Carlos
Williams
On Mon, 12 Dec 2005, Piotr Majdak wrote:
BTW, I don't think pd needs international localization in the current development state. There are many another issues (stability, transparency, documentation) which should get higher priority than localization if pd wants to reach for more users.
I don't think you get the priority thing right. What happens is that there are many people who would only contribute to Pd in the form of translations, so, in effect, the #1 priority thing on their to-do list would be to translate things, if it's something we allow them to do.
And then there are motivational factors. 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.
BTW, could you please elaborate on what you consider to be transparency?
Because it isn't clear to me... (I bet it doesn't have anything to do
with alpha channels... ;-)
_ _ __ ___ _____ ________ _____________ _____________________ ... | 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, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
für German, it makes more sense to use the Reverse Polish Notation (RPN) as commonly used in Forth, PostScript, and HP calculators. e.g.: 1 2 sende-nachricht
However: German is not RPN, the word order in a sentence is very similar to the one in English
"German books are easy enough to read when you hold them before the looking-glass or stand on your head--so as to reverse the construction--but I think that to learn to read and understand a German newspaper is a thing which must always remain an impossibility to a foreigner." -- Mark Twain 1880
« There are ten parts of speech, and they are all troublesome. An average sentence, in a German newspaper, is a sublime and impressive curiosity; it occupies a quarter of a column; it contains all the ten parts of speech--not in regular order, but mixed; it is built mainly of compound words constructed by the writer on the spot, and not to be found in any dictionary--six or seven words compacted into one, without joint or seam--that is, without hyphens; it treats of fourteen or fifteen different subjects, each enclosed in a parenthesis of its own, with here and there extra parentheses, making pens with pens: finally, all the parentheses and reparentheses are massed together between a couple of king-parentheses, one of which is placed in the first line of the majestic sentence and the other in the middle of the last line of it--AFTER WHICH COMES THE VERB, and you find out for the first time what the man has been talking about; and after the verb--merely by way of ornament, as far as I can make out--the writer shovels in "HABEN SIND GEWESEN GEHABT HAVEN GEWORDEN SEIN," or words to that effect, and the monument is finished. » -- Mark Twain 1880
and not similar to Yoda. (Maybe it's this way in, uhm, Polish?)
RPN is the reverse version of Polish Notation, which makes all operators prefix, as in LISP, but not necessarily with the same syntax. E.g. 2+2 is then written +(2,2) or +(2 2) or (+ 2 2) depending on the variant of PN.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Mon, 12 Dec 2005, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
fÃŒr German, it makes more sense to use the Reverse Polish Notation (RPN) as commonly used in Forth, PostScript, and HP calculators. e.g.: 1 2 sende-nachricht
However: German is not RPN, the word order in a sentence is very similar to the one in English
"German books are easy enough to read when you hold them before the looking-glass or stand on your head--so as to reverse the construction--but I think that to learn to read and understand a German newspaper is a thing which must always remain an impossibility to a foreigner." -- Mark Twain 1880
Well, in subordinate clauses the predicate indeed comes last, which is different from English. However in main clauses the predicate always is "infix" in German as well, so yodaish sounds as funny to us as to you.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
B. Bogart -
derek holzer -
Frank Barknecht -
geiger -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Krzysztof Czaja -
Marc Lavallée -
Mathieu Bouchard -
Max Neupert -
Piotr Majdak -
Thomas Grill -
vincent rioux