To those beginners in programming that are not English speakers there are 3 problems to be solved: 1) the logic (this is unavoidable) 2) the programming language (hard but quite simple) 3) the messages (hard and not simple) Those who could not cope with (1) could not be programmers (2) difficult but not the main (so a 2nd step) (3) the worst but more treatable and more largely useful The i18n of (2) is mainly to be used in initial stages and could not be generally applicable (maybe just some European languages). This probably could require to rewrote the scanner (or maybe only the grammar, I haven't gone so deep yet) so it's not that big of a problem, it hardly affects the parser and interpreter, that are the more complex tasks. If (3) could enter the main trunk it would be a great help by itself. In this case access to international help is useless due the original difficulties with the language, remember I'm talking about kids mainly, and 1st stage to programming for youngsters. There are two main ways to do this, one is using codes as indicated, but I prefer using the more generally accepted and used, with messages catalogs using gettext and the like. Any way thanks for your comments. Alcino 2010/8/17 Anders Sandvig <anders.sandvig@gmail.com>
On Wed, Aug 25, 2010 at 10:59 AM, Alcino Dall'Igna Jr <adijbr@gmail.com> wrote:
IMO (2) is a bad idea. You'd have to translate not just the keywords but also the builtins and the standard library. Or else your users would still live in a mixed-world and the benefit would be minimal. But translating the stdlib is too much work. (It can't be fully automated, due to things like getattr(x, 'foo').) There's also the danger that users would write code in their local dialect and expect to share it with others in another locale. Let them read and write broken English, it's unavoidable anyway! (Probably they know more broken English than you think. After all they are using computers already. :-)
That sounds painful, but in general I am okay with the idea of translating messages. I think the system messages (those that go with IOError and OSError) may already be translated. How to do it without off-putting the core developers may end up being a research problem. :-) -- --Guido van Rossum (python.org/~guido)
On 25/08/2010 21:26, Guido van Rossum wrote:
+1 - a difficult problem to solve (socially and architecturally but not technologically) but users are likely to appreciate it. A downside (from experience with .NET which takes this approach - logic and class names are all English but error messages are localized) is that you then get bug reports with localized error messages. It makes frequent visits to google translate unavoidable... All the best, Michael -- http://www.ironpythoninaction.com/
On 8/25/2010 2:31 PM, Michael Foord wrote:
On 25/08/2010 21:26, Guido van Rossum wrote:
[snip...]
Localized messages should be in addition to rather than a replacement for the English version. I thought we had this discussion somewhere -- here? ideas? maybe a tracker issue? -- Terry Jan Reedy
On Thu, Aug 26, 2010 at 6:26 AM, Terry Reedy <tjreedy@udel.edu> wrote:
I remember the same discussion, and yeah, the final position was that including the original English text along with the localised text made the most sense. The idea didn't really go anywhere after that though, since it is still a *lot* of work. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 8/25/2010 5:41 PM, Nick Coghlan wrote:
Just after posting, I went to python-list, and read a response from OP asked to paste the traceback for his problem: ... File "C:\Python26\lib\socket.py", line 406, in readline data = self._sock.recv(self._rbufsize) socket.error: [Errno 10054] A lÚtez§ kapcsolatot a tßvoli ßllomßs kÚnyszerÝtette n bezßrta Fortunately, the OP could translate back well enough to "So this message is meaning that the remote station forced close the existing connection." and get additional help from other respondents. So the idea, at least, of giving both versions would be a good one ;-). -- Terry Jan Reedy
Terry Reedy:
That is pretty good mojibake. One of the problems of providing localized error messages is that the messages may be messed up at different stages. The original text was A létező kapcsolatot a távoli állomás kényszerítetten bezárta. It was printed in iso8859_2 (ISO standard for Eastern European) then those bytes were pasted in as if they were cp852 (MS-DOS Eastern European). text = "A létező kapcsolatot a távoli állomás kényszerítetten bezárta." print(str(text.encode('iso8859_2'), 'cp852')) Neil
That's an old Python 2.x bug. The message was probably printed in a terminal Window, yet Python did not recode it from what Windows provided (and indeed, it couldn't, because it couldn't know what encoding the exception string was in when it printed it). I believe this is fixed in Python 3, which uses a Unicode string for the text. Regards, Martin
Terry Reedy wrote:
This could be done as a free-standing library, there's no reason to involve core CPython. Just do message translation at a later stage, e.g. in a custom sys.excepthook. I did a quick demo: | Python 3.2a1 (r32a1:83346, Jul 31 2010, 18:36:39) [MSC v.1500 32 bit (Intel)] on | win32 | Type "help", "copyright", "credits" or "license" for more information. | >>> import localise_exceptions | >>> localise_exceptions.install_excepthook('DK') | >>> None.no_such_attr | Traceback (most recent call last): | | File "<stdin>", line 1, in <module> | | AttributeError: 'NoneType' objektet har ingen attribut 'no_such_attr' localise_exceptions.py is at http://pastebin.com/QJCn8gmd regards, Anders
On Wed, Aug 25, 2010 at 10:42 PM, Anders J. Munch <ajm@flonidan.dk> wrote:
It could be done as a free standing library, but if this idea gets traction, it might be nice to incorporate it into the standard library, so inexperienced Pythoneers wouldn't have to do anything more onerous than "import localizedexceptions" in their interactive console. Using easy_install or whatever to add a new module can be tough in, say, a school environment where you don't have control of the machines you are using. I suppose the sensible thing to do is to recruit people for an independent project first and see if it gains traction. If it does, then pull it into the standard library a few years down the road. Incidentally, on the topic of translating keywords and such, it looks like one project to do so, Chinese Python, hasn't been updated since 2004: http://www.chinesepython.org/cgi_bin/cgb.cgi/news/news.html I just don't think there's much demand for translating the keywords. -- Carl Johnson
did this with their Word and Excel-Functions, and it is a source of frustration. While learning any programming language, you're learning new concepts anyway. new concepts = new words. Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - Using PostgreSQL is mostly about sleeping well at night.
-On [20100825 20:03], Alcino Dall'Igna Jr (adijbr@gmail.com) wrote:
Haven't been able to respond sooner, but maybe one thing was not so clear about what I wrote since you misrepresented it here. What I was referring to was this scenario: ImportError: No module named blah would become in nl_NL something like: ImportError: Geen module genaamd blah Now, if ImportError (or any other error) has only one text, then I could copy-paste that error message easily and people would understand contextually from the error which it is, despite the localization. However, if there's multiple possible messages, how is someone else supposed to figure out what my localized message means in order to help me out? In this case I think an approach with a number inventory system works out well, e.g.: ImportError (3): Geen module genaamd blah And the 3 would be a stable number for this particular message. More examples: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.ase_15.0.... Oracle: en_US: ORA-00942: table or view does not exist ja_JP: ORA-00942: 表またはビューが存在しません。 -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B When you meet a master in the street, do not speak, do not be silent. Then how will you greet him?
On Wed, Aug 25, 2010 at 10:59 AM, Alcino Dall'Igna Jr <adijbr@gmail.com> wrote:
IMO (2) is a bad idea. You'd have to translate not just the keywords but also the builtins and the standard library. Or else your users would still live in a mixed-world and the benefit would be minimal. But translating the stdlib is too much work. (It can't be fully automated, due to things like getattr(x, 'foo').) There's also the danger that users would write code in their local dialect and expect to share it with others in another locale. Let them read and write broken English, it's unavoidable anyway! (Probably they know more broken English than you think. After all they are using computers already. :-)
That sounds painful, but in general I am okay with the idea of translating messages. I think the system messages (those that go with IOError and OSError) may already be translated. How to do it without off-putting the core developers may end up being a research problem. :-) -- --Guido van Rossum (python.org/~guido)
On 25/08/2010 21:26, Guido van Rossum wrote:
+1 - a difficult problem to solve (socially and architecturally but not technologically) but users are likely to appreciate it. A downside (from experience with .NET which takes this approach - logic and class names are all English but error messages are localized) is that you then get bug reports with localized error messages. It makes frequent visits to google translate unavoidable... All the best, Michael -- http://www.ironpythoninaction.com/
On 8/25/2010 2:31 PM, Michael Foord wrote:
On 25/08/2010 21:26, Guido van Rossum wrote:
[snip...]
Localized messages should be in addition to rather than a replacement for the English version. I thought we had this discussion somewhere -- here? ideas? maybe a tracker issue? -- Terry Jan Reedy
On Thu, Aug 26, 2010 at 6:26 AM, Terry Reedy <tjreedy@udel.edu> wrote:
I remember the same discussion, and yeah, the final position was that including the original English text along with the localised text made the most sense. The idea didn't really go anywhere after that though, since it is still a *lot* of work. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 8/25/2010 5:41 PM, Nick Coghlan wrote:
Just after posting, I went to python-list, and read a response from OP asked to paste the traceback for his problem: ... File "C:\Python26\lib\socket.py", line 406, in readline data = self._sock.recv(self._rbufsize) socket.error: [Errno 10054] A lÚtez§ kapcsolatot a tßvoli ßllomßs kÚnyszerÝtette n bezßrta Fortunately, the OP could translate back well enough to "So this message is meaning that the remote station forced close the existing connection." and get additional help from other respondents. So the idea, at least, of giving both versions would be a good one ;-). -- Terry Jan Reedy
Terry Reedy:
That is pretty good mojibake. One of the problems of providing localized error messages is that the messages may be messed up at different stages. The original text was A létező kapcsolatot a távoli állomás kényszerítetten bezárta. It was printed in iso8859_2 (ISO standard for Eastern European) then those bytes were pasted in as if they were cp852 (MS-DOS Eastern European). text = "A létező kapcsolatot a távoli állomás kényszerítetten bezárta." print(str(text.encode('iso8859_2'), 'cp852')) Neil
That's an old Python 2.x bug. The message was probably printed in a terminal Window, yet Python did not recode it from what Windows provided (and indeed, it couldn't, because it couldn't know what encoding the exception string was in when it printed it). I believe this is fixed in Python 3, which uses a Unicode string for the text. Regards, Martin
Terry Reedy wrote:
This could be done as a free-standing library, there's no reason to involve core CPython. Just do message translation at a later stage, e.g. in a custom sys.excepthook. I did a quick demo: | Python 3.2a1 (r32a1:83346, Jul 31 2010, 18:36:39) [MSC v.1500 32 bit (Intel)] on | win32 | Type "help", "copyright", "credits" or "license" for more information. | >>> import localise_exceptions | >>> localise_exceptions.install_excepthook('DK') | >>> None.no_such_attr | Traceback (most recent call last): | | File "<stdin>", line 1, in <module> | | AttributeError: 'NoneType' objektet har ingen attribut 'no_such_attr' localise_exceptions.py is at http://pastebin.com/QJCn8gmd regards, Anders
On Wed, Aug 25, 2010 at 10:42 PM, Anders J. Munch <ajm@flonidan.dk> wrote:
It could be done as a free standing library, but if this idea gets traction, it might be nice to incorporate it into the standard library, so inexperienced Pythoneers wouldn't have to do anything more onerous than "import localizedexceptions" in their interactive console. Using easy_install or whatever to add a new module can be tough in, say, a school environment where you don't have control of the machines you are using. I suppose the sensible thing to do is to recruit people for an independent project first and see if it gains traction. If it does, then pull it into the standard library a few years down the road. Incidentally, on the topic of translating keywords and such, it looks like one project to do so, Chinese Python, hasn't been updated since 2004: http://www.chinesepython.org/cgi_bin/cgb.cgi/news/news.html I just don't think there's much demand for translating the keywords. -- Carl Johnson
did this with their Word and Excel-Functions, and it is a source of frustration. While learning any programming language, you're learning new concepts anyway. new concepts = new words. Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - Using PostgreSQL is mostly about sleeping well at night.
-On [20100825 20:03], Alcino Dall'Igna Jr (adijbr@gmail.com) wrote:
Haven't been able to respond sooner, but maybe one thing was not so clear about what I wrote since you misrepresented it here. What I was referring to was this scenario: ImportError: No module named blah would become in nl_NL something like: ImportError: Geen module genaamd blah Now, if ImportError (or any other error) has only one text, then I could copy-paste that error message easily and people would understand contextually from the error which it is, despite the localization. However, if there's multiple possible messages, how is someone else supposed to figure out what my localized message means in order to help me out? In this case I think an approach with a number inventory system works out well, e.g.: ImportError (3): Geen module genaamd blah And the 3 would be a stable number for this particular message. More examples: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.ase_15.0.... Oracle: en_US: ORA-00942: table or view does not exist ja_JP: ORA-00942: 表またはビューが存在しません。 -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B When you meet a master in the street, do not speak, do not be silent. Then how will you greet him?
participants (11)
-
"Martin v. Löwis" -
Alcino Dall'Igna Jr -
Anders J. Munch -
Carl M. Johnson -
Guido van Rossum -
Jeroen Ruigrok van der Werven -
Massa, Harald Armin -
Michael Foord -
Neil Hodgson -
Nick Coghlan -
Terry Reedy