Beefy Boxes and Bandwidth Generously Provided by pair Networks Frank
Don't ask to ask, just ask
 
PerlMonks  

Writing localized Perl apps

by flyingmoose (Priest)
on Apr 30, 2004 at 19:41 UTC ( #349494=perlquestion: print w/ replies, xml ) Need Help??
flyingmoose has asked for the wisdom of the Perl Monks concerning the following question:

So I work with a lot of Java (ack!) software that is translated into about 8 languages. We have string files for this that work very well. I understand the language bundle philosophy pretty well, rules about not concatenating strings, implications on subject/verb agreement, avoidance of hard coded strings, etc. Problem is, I'm always writing Perl apps without any regard for other languages. This isn't cool.

I'm wondering how similar things are done in Perl, what modules are most highly favored (for string files as well as dealing with locales), are there any strange corners where some things don't play nicely with utf8, etc... I saw some comment in another thread about 'localizing $_' ... what does this mean? Do standard perl explanations like $! vary based on locale, or must I avoid using them? What to do about international time & date formats (i.e. Germany doesn't use AM/PM), etc?

Any pointers? I'm probably not going to need this for some time, but I can feel the question incoming -- "Why is this only offered in English?"

And yes, my non-English language skills are limited, so please be kind. lo siento, yo soy uno rhinoceronte. Hay mantequilla en la silla.. See, totally incoherrent. I am a Jelly Donut :)

Comment on Writing localized Perl apps
Re: Writing localized Perl apps
by dragonchild (Archbishop) on Apr 30, 2004 at 20:01 UTC
    In working with PDF::Template, I had to deal with this directly because I was working on an app that was seamlessly presented in 12 languages. The short answer is that Perl 5.8+ treats strings as purely Unicode.

    Before that, you pretty much have to use Unicode::String and accept the performance penalties (which are quite significant). *shrugs*

    Now, Parrot-targeted languages will have Unicode built into the ASM (as it were), but I'd direct anyone interested in this to read the parrot mailing list for more info.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      Yes, there has been a long running discussion on this on the perl6-internals mailing list here and here for anyone interested.

Re: Writing localized Perl apps
by simonm (Vicar) on Apr 30, 2004 at 20:34 UTC
    I'm not an expert in this area, but try looking at the Maketext modules. They seem to be a very Perl-ish solution to this problem area.

    P.S.: I saw some comment in another thread about 'localizing $_'

    That was probably a reference to dynamic scoping with local() rather than localization.

    P.P.S.: See also the perl.i18n mailing list and Sean Burke's article on Locale::MakeText in TPJ #13.

Re: Writing localized Perl apps
by allolex (Curate) on Apr 30, 2004 at 22:26 UTC

    I use POSIX locales with HTML::Template or SSI for internationalization. It works pretty well. I'm sure any decent templating system would do (Template Toolkit, anyone?).

    use locale; use POSIX 'locale_h'; my $loc = "de_DE.utf-8"; setlocale(LC_CTYPE, $loc) or die "Invalid locale $loc";

    This code is probably from perllocale, which is another great source for this sort of thing.

    BTW AM/PM is AFAIK strictly an Anglophone thing. No other language uses it. But the one that really gets you is the decimal/comma inversion on the European continent: 3,14 vs 300.000.000 EUR or 300 000 000 EUR. =)

    --
    Damon Allen Davison
    http://www.allolex.net

Re: Writing localized Perl apps
by Jouke (Curate) on May 01, 2004 at 11:23 UTC
Re: Writing localized Perl apps
by crenz (Priest) on May 02, 2004 at 19:33 UTC

    I also tend to use maketext, as there are utilities like poEdit to handle the language files.

    As for your other questions:

    • localizing $_ relates to scoping problems of the variable $_. It doesn't have to do anything with localization.
    • I haven't seen a non-English error message from Perl so far. This is not a huge deal, as users shouldn't see Perl's messages anyway.
    • if you use locale, a number of things will be adapted to the current locale. For example, in a German locale, sprintf() will format a floating point number as 1,25 instead of 1.25. strftime (from the POSIX module) will format date and time strings correctly according to the current locale (e.g. Mi 13. Januar 2004, 17:52 instead of Wed, January 13th 2004, 5:52pm. Also, the sorting order will be affected by the locale (e.g. in sort).

    Go and read perllocale, it has some more interesting information. For example, you can also find out the currency symbol of the current locale so you can print 100 or 100 instead of $100.

    One last hint: Whatever approach you use, use a format that comes with tools like poEdit or is easy to understand. The better your software is and the easier it is to translate it, the more people will volunteer to translate it to another language (talking in a open source context, not business, of course).

Re: Writing localized Perl apps
by BigLug (Chaplain) on May 02, 2004 at 21:49 UTC
    When working with Dates, your best bet for localization (or localisation, depending on your locale), is the DateTime suite of modules. The DateTime project has been anally-retentive with it's dates. Not only does it use the Olsen Time Zone database to make sure it moves to and from DST at the right time this year, but it does it at the right time back to 1972, so if your local laws have changed, so has the database.

    However that's not what you asked about.

    The other thing that DateTime handles is locales. For this, it has used the Common XML Locale Repository project. So, once you have your DateTime object, all you need to do is set the locale and output it with strftime. All the strftime functions are localised, so getting the month name will always return the name in the current locale. The %c token is the default date-and-time format for the locale:

    use DateTime; $dt = DateTime->now(); print $dt->set( locale => 'en' )->strftime('%c') . "\n"; # May 2, 2004 9:45:18 PM print $dt->set( locale => 'en_AU' )->strftime('%c') . "\n"; # 02/05/2004 9:45:18 PM print $dt->set( locale => 'es' )->strftime('%c') . "\n"; # 02-may-04 21:45:18 print $dt->set( locale => 'fr' )->strftime('%c') . "\n"; # 2 mai 04 21:45:18 print $dt->set( locale => 'it' )->strftime('%c') . "\n"; # 02/mag/04 21:45:18 print $dt->set( locale => 'no' )->strftime('%c') . "\n"; # 02.mai.04 21:45:18
    "Get real! This is a discussion group, not a helpdesk. You post something, we discuss its implications. If the discussion happens to answer a question you've asked, that's incidental." -- nobull@mail.com in clpm

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://349494]
Approved by fglock
Front-paged by grinder
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (8)
As of 2014-04-17 10:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (444 votes), past polls