« Status Update on Catalyst-ActionRole-BuildDBICResult | Main | Catalyst::ActionRole::BuildDBICResult Update »

06/07/2010

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

phaylon

I have to say, I've never been particularly fond of localised error and debugging messages for the following reasons: a) It makes it harder to Googleb) harder to ensure that translated error messages are accurate and stay that wayc) it looks weirdish when it's incompleted) it would make it harder to give support, since the messages would have to be reversed to one of the supported core languages or you'd have to find a volunteer knowing the language.

John Napiorkowski

No doubt it would make things harder, and I understand what you are saying. I just wonder if not having it is alienating non English devs. However from what I can see in some of the frameworks coming from non English locations I am not seeing localized errors so much so many its cool. Would love to hear from some people not from an English native country about this.

phaylon

They won't get past most documentation on CPAN either if they are stopped by an English error message; not to mention the source code itself, but that's more idiomatic than actual text. Also, in my personal experience, English is simply an important cornerstone in software development today. In Open Source probably even more than anything else.Also, I am from a non-English country :)

John Napiorkowski

hey,Where are you originally? Just wondering (not coming on to you or anything ;)

Illusori

First of all, I'm a native English speaker, and speak no other languages at all, so in that sense I'm not qualified to answer this... however I won't let it stop me forming and sharing an opinion. :) :)The key thing to me is do you have a localized API too?If the main interaction your end-user developers are having with your software is via an English-language API, it makes little sense to me to then localize the error messages that they hopefully be seeing less frequently.I could of course be wrong, and it could be a great help to people, but it seems to me that if someone needed help with the error message, they'd probably find language issues in everything else insurmountable.The handful of times I've worked with code written in a non-English language, it was function and variable names that gave me the trouble, error messages have a small enough dictionary of words that you can kinda fill in the blanks even if you don't speak the language.The Google searching is a good point, it's often a good short-cut to finding a solution if you've got a problem you can't figure out yourself, it could probably be addressed by providing both English and localized language descriptions in the error string.

phaylon

Originally from Austria, now living in Hamburg :)I think illusori's post formulated my concerns very nicely. At the moment, by means of pseudo-standardization to English, the terminology, the API, documentation, and messages are in sync. So a translation effort should involve a broader spectrum than just error messages, and that requires sufficient internationally decentralized tuits to keep up to date.

Jakub Narębski

Note that both mentioned solutions use Perl-specific Locale::Maketext for localization: Catalyst::Plugin::I18N via Locale::Maketext::Simple, and
Catalyst::Model::Data::Localize via Data::Localize, object-oriented wrapper around Locale::Maketext.

I wonder if there are solutions that use Locale::Gettext / Locale::TextDomain from libintl-perl for Catalyst; see On the state of i18n in Perl blog post from 2009 (rather than relying on outdated Locale::Maketext::TPJ13 article from 1999).

Jakub Narębski



The Google searching is a good point, it's often a
good short-cut to finding a solution if you've got a problem you can't
figure out yourself, it could probably be addressed by providing both
English and localized language descriptions in the error string.

Or provide easy way to turn on English language; for command line
app it would be LC_ALL=C, for a web app it could be '.en.html' suffix,
or '/en/' in path_info.

John Napiorkowski

A quick look at Data::Localize indicate support for gettext. Please take a look:http://search.cpan.org/~dmaki/Data-Localize-0.00016/http://search.cpan.org/~dmaki/Data-Localize-0.00016/lib/Data/Localize/Gettext.pmand let me know what you think. Regarding Catalyst, although Catalyst::Plugin::I18N is the documented way to do this my understanding is that many people are interested in Data::Localize and plan to use those tools in upcoming projects.Thanks for your information, I personally found it very usefulJohn

Nilson Santos F. Jr.

[this is good] As a Brazilian Perl user, I actually prefer everything in English. I think I'm sort of qualified to answer this as Portuguese has no resemblance to English at all and here it's not like in India where a good percentage of people learn English.First of all, a lot of the translations of tech expressions to Portuguese sound very odd and a lot of developers will understand the English version but not the correct translation to Portuguese.Second point is... I'm currently working with Oracle and it spits out localized error messages. What a nightmare! If Oracle errors weren't already cryptic enough, not being able to Google them and get useful results is a double nightmare.

John Napiorkowski

Nilson,Thanks for you input. Starting to sound like simply concentrating on just making better error messages would be a better use of time.John

Jakub Narębski

The problem with using gettext lexicon with Locale::Maketext or Data::Localize is that for more advanced forms (like dealing with plural forms) it is Maketext-ty solution (like 'quant') and not gettext-ty solution (like 'ngettext'). The blog post I have mentioned describes this problem well.

John Napiorkowski

So, would you recommend Data::Localize (which is designed as a sort of wrapper around different localization) have a parser based on the tools you mentioned? I'm not a localization expert when it comes to the types of problems you are mentioning, but this seems reasonable.

Jakub Narębski

What I would like to see is Catalyst plugin or model based on Locale::Messages or high-level Locale::TextDomain wparrer (on libintl-perl) rather than on Locale::Maketext (with Locale::Maketext::Simple or Data::Localize high-level wrapper), even using gettext as Locale::Maketext lexicon.

Curtis Jewell

My answer to the internationalization question would be to put a unique code in the error output that isn't translated, and then have the error message translated...Either that and/or dump a stacktrace.Not that I'm following my own advice yet, but either one would allow you to locate where the error is.

John Napiorkowski

Great comments everyone, I learned I know pretty much next to nothing about internationalization :) However I'm closing comments since this post is attracting spam and I don't have time to keep logging in to delete them. I'll try to post a followup once I digest all the information shared.Thanks again!

The comments to this entry are closed.