FAQ
Hi,

Has any anybody got a working example of the use of Locale::Maketext with Locale::Maketext::Lexicon? I think I've missed something simple. My example code is:

{ package Lexicon;

use base 'Locale::Maketext';
use Locale::Maketext::Lexicon {
fr => ['Gettext' => "hello_fr2.po" ],
};

sub fr::xxx { print "Hello!"; return "hello"; }

1;

}

my $l = Lexicon->get_handle( 'fr' );

print $l->maketext( "Hello" ) . "\n";

print $l->maketext( "Nuts ~[xxx~]" ) . "\n";

The hello_fr2.po contains:

msgid "Hello"
msgstr "Bonjour"

msgid "Goodbye"
msgstr "Au revoir"

msgid "Your search matched [quant,_1,book]"
msgstr "Vous trouvez [ quant, _1, livre ]"

msgid "You are my [ord,_1] something."

msgid "[numf,_1]"
msgstr "[numf,_1]"

msgid "Nuts [xxx]"
msgstr "Bolts [xxx]"

The output is:

Bonjour
Bolts [xxx]

So the simple substitutions work but I can't get it to call the function. Furthermore, it puts tilde before each bracket, so I can't get a match for anything with a function unless I put tildes in there. I've missed something simple. Any ideas?

Thanks

Duncan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20111006/445c0c60/attachment.htm

Search Discussions

  • Chakkit Ngamsom at Oct 6, 2011 at 2:05 pm
    Hi Duncan,

    You should use Plugin here:
    http://search.cpan.org/dist/Catalyst-Plugin-I18N/lib/Catalyst/Plugin/I18N.pm

    Check at configuration section if you want to specify directory for .po files or elsr.

    Regards,
    Chakkit
    On Oct 6, 2011, at 7:39 PM, Duncan Garland wrote:

    Hi,



    Has any anybody got a working example of the use of Locale::Maketext with Locale::Maketext::Lexicon? I think I?ve missed something simple. My example code is:



    { package Lexicon;



    use base 'Locale::Maketext';

    use Locale::Maketext::Lexicon {

    fr => ['Gettext' => "hello_fr2.po" ],

    };



    sub fr::xxx { print "Hello!"; return "hello"; }



    1;



    }



    my $l = Lexicon->get_handle( 'fr' );



    print $l->maketext( "Hello" ) . "\n";



    print $l->maketext( "Nuts ~[xxx~]" ) . "\n";



    The hello_fr2.po contains:



    msgid "Hello"

    msgstr "Bonjour"



    msgid "Goodbye"

    msgstr "Au revoir"



    msgid "Your search matched [quant,_1,book]"

    msgstr "Vous trouvez [ quant, _1, livre ]"



    msgid "You are my [ord,_1] something."



    msgid "[numf,_1]"

    msgstr "[numf,_1]"



    msgid "Nuts [xxx]"

    msgstr "Bolts [xxx]"



    The output is:



    Bonjour

    Bolts [xxx]



    So the simple substitutions work but I can?t get it to call the function. Furthermore, it puts tilde before each bracket, so I can?t get a match for anything with a function unless I put tildes in there. I?ve missed something simple. Any ideas?



    Thanks



    Duncan





    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20111006/0eb383ec/attachment.htm
  • Duncan Garland at Oct 6, 2011 at 3:08 pm
    Hi Chakkit,

    Thanks for your reply.

    We do have a medium sized Catalyst application which we may well want to internationalise at some point, but at the moment I’m looking for a solution which can be applied to some other non-Catalyst applications.

    I posted my question here because I got the idea of using Locale::Maketext and Locale::Maketext::Lexicon from the articles referenced on the Catalyst localisation man page. Specifically, there is an article by Audrey Tang which gives an example which seems to do exactly what we want. (Multiple .po files per language which are searched in order and the ability to include some functions.) I also got the impression that these modules are commonly used within the Catalyst community.

    Unfortunately, I can’t make the example code work and I can’t find a better example.

    I’ve had the debugger on the code for a while since I made my first post.

    The problems are:


    1) The square brackets are escaped with a tilde to become ~[ or ~] when they are read in. That applies to both the msgid and the msgstr.

    2) The code which compiles the subroutine does recognise ~ but treats it as escaping the bracket. Thus the in_group flag is never set and it never constructs or executes the function. If I use the debugger to remove the tildes, the function is built and executed.

    3) The article implies that you declare a function as fr::xxx and call it as xxx. In fact, if it is declared as fr::xxx it must be called as fr::xxx.

    I’ve run out of ideas.

    All the best.

    Duncan
    From: Chakkit Ngamsom
    Sent: 06 October 2011 15:06
    To: The elegant MVC web framework
    Subject: Re: [Catalyst] Localisation

    Hi Duncan,

    You should use Plugin here:
    http://search.cpan.org/dist/Catalyst-Plugin-I18N/lib/Catalyst/Plugin/I18N.pm

    Check at configuration section if you want to specify directory for .po files or elsr.

    Regards,
    Chakkit

    On Oct 6, 2011, at 7:39 PM, Duncan Garland wrote:
    Hi,

    Has any anybody got a working example of the use of Locale::Maketext with Locale::Maketext::Lexicon? I think I’ve missed something simple. My example code is:

    { package Lexicon;

    use base 'Locale::Maketext';
    use Locale::Maketext::Lexicon {
    fr => ['Gettext' => "hello_fr2.po" ],
    };

    sub fr::xxx { print "Hello!"; return "hello"; }

    1;

    }

    my $l = Lexicon->get_handle( 'fr' );

    print $l->maketext( "Hello" ) . "\n";

    print $l->maketext( "Nuts ~[xxx~]" ) . "\n";

    The hello_fr2.po contains:

    msgid "Hello"
    msgstr "Bonjour"

    msgid "Goodbye"
    msgstr "Au revoir"

    msgid "Your search matched [quant,_1,book]"
    msgstr "Vous trouvez [ quant, _1, livre ]"

    msgid "You are my [ord,_1] something."

    msgid "[numf,_1]"
    msgstr "[numf,_1]"

    msgid "Nuts [xxx]"
    msgstr "Bolts [xxx]"

    The output is:

    Bonjour
    Bolts [xxx]

    So the simple substitutions work but I can’t get it to call the function. Furthermore, it puts tilde before each bracket, so I can’t get a match for anything with a function unless I put tildes in there. I’ve missed something simple. Any ideas?

    Thanks

    Duncan


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20111006/4860e681/attachment.htm
  • Duncan Garland at Oct 6, 2011 at 3:48 pm
    There is some pod buried deep in Locale::Maketext::Lexicon::Gettext. You have to use different syntax in the .po file. If anybody’s interested, the following simple example does work:

    { package Lexicon;

    use base 'Locale::Maketext';
    use Locale::Maketext::Lexicon {
    fr => ['Gettext' => "hello_fr2.po" ],
    };

    sub xxx { print "Hello!"; return "hello"; }

    1;

    }

    my $l = Lexicon->get_handle( 'fr' );

    print $l->maketext( "Hello" ) . "\n";

    print $l->maketext( "Nuts" ) . "\n";

    The .po file:

    msgid "Hello"
    msgstr "Bonjour"

    msgid "Goodbye"
    msgstr "Au revoir"

    msgid "Nuts"
    msgstr "Bolts %xxx()"

    Output:

    Bonjour
    Hello!Bolts hello

    Regards

    Duncan
    From: Duncan Garland
    Sent: 06 October 2011 16:09
    To: The elegant MVC web framework
    Subject: RE: [Catalyst] Localisation

    Hi Chakkit,

    Thanks for your reply.

    We do have a medium sized Catalyst application which we may well want to internationalise at some point, but at the moment I’m looking for a solution which can be applied to some other non-Catalyst applications.

    I posted my question here because I got the idea of using Locale::Maketext and Locale::Maketext::Lexicon from the articles referenced on the Catalyst localisation man page. Specifically, there is an article by Audrey Tang which gives an example which seems to do exactly what we want. (Multiple .po files per language which are searched in order and the ability to include some functions.) I also got the impression that these modules are commonly used within the Catalyst community.

    Unfortunately, I can’t make the example code work and I can’t find a better example.

    I’ve had the debugger on the code for a while since I made my first post.

    The problems are:


    1) The square brackets are escaped with a tilde to become ~[ or ~] when they are read in. That applies to both the msgid and the msgstr.

    2) The code which compiles the subroutine does recognise ~ but treats it as escaping the bracket. Thus the in_group flag is never set and it never constructs or executes the function. If I use the debugger to remove the tildes, the function is built and executed.

    3) The article implies that you declare a function as fr::xxx and call it as xxx. In fact, if it is declared as fr::xxx it must be called as fr::xxx.

    I’ve run out of ideas.

    All the best.

    Duncan
    From: Chakkit Ngamsom
    Sent: 06 October 2011 15:06
    To: The elegant MVC web framework
    Subject: Re: [Catalyst] Localisation

    Hi Duncan,

    You should use Plugin here:
    http://search.cpan.org/dist/Catalyst-Plugin-I18N/lib/Catalyst/Plugin/I18N.pm

    Check at configuration section if you want to specify directory for .po files or elsr.

    Regards,
    Chakkit

    On Oct 6, 2011, at 7:39 PM, Duncan Garland wrote:
    Hi,

    Has any anybody got a working example of the use of Locale::Maketext with Locale::Maketext::Lexicon? I think I’ve missed something simple. My example code is:

    { package Lexicon;

    use base 'Locale::Maketext';
    use Locale::Maketext::Lexicon {
    fr => ['Gettext' => "hello_fr2.po" ],
    };

    sub fr::xxx { print "Hello!"; return "hello"; }

    1;

    }

    my $l = Lexicon->get_handle( 'fr' );

    print $l->maketext( "Hello" ) . "\n";

    print $l->maketext( "Nuts ~[xxx~]" ) . "\n";

    The hello_fr2.po contains:

    msgid "Hello"
    msgstr "Bonjour"

    msgid "Goodbye"
    msgstr "Au revoir"

    msgid "Your search matched [quant,_1,book]"
    msgstr "Vous trouvez [ quant, _1, livre ]"

    msgid "You are my [ord,_1] something."

    msgid "[numf,_1]"
    msgstr "[numf,_1]"

    msgid "Nuts [xxx]"
    msgstr "Bolts [xxx]"

    The output is:

    Bonjour
    Bolts [xxx]

    So the simple substitutions work but I can’t get it to call the function. Furthermore, it puts tilde before each bracket, so I can’t get a match for anything with a function unless I put tildes in there. I’ve missed something simple. Any ideas?

    Thanks

    Duncan


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20111006/d76b5cc7/attachment.htm
  • André Walker at Oct 6, 2011 at 4:06 pm
    I don't know if it helps, but I've been researching a little about
    localization recently, and I came across this article:
    http://rassie.org/archives/247

    In summary, it states Locale::Maketext shouldn't be used ? we should be
    using Locale::TextDomain instead. I'm considering it for my current needs.

    Any thoughts?

    Regards,
    Andr?
  • Duncan Garland at Oct 6, 2011 at 4:42 pm
    Hi,

    I hadn't seen this and I've only just had a quick glance through it. However, it contains some obvious errors. The most glaring is that Maketext does allow the word order to be swopped in the output although I think the parameter order has to be the same.

    Msgid "[xxx, 1, 2]"
    Msgstr "[xxx, 1, 2]"

    The function which outputs the translation for xxx can easily be made to return "1,2" or "2,1".

    I'm not sure what he means by Voodoo but I thought simple functions such as quant were pre-implemented in many languages. I also find it hard to believe that there aren't some pre-written lexicons available. The perl community is very good at that.

    Not sure about the rest. I only started looking at this a couple of days ago and I've only just extricated myself from that knot I got into with the syntax.

    All the best.

    Duncan

    -----Original Message-----
    From: Andr? Walker
    Sent: 06 October 2011 17:07
    To: The elegant MVC web framework
    Subject: Re: [Catalyst] Localisation

    I don't know if it helps, but I've been researching a little about
    localization recently, and I came across this article:
    http://rassie.org/archives/247

    In summary, it states Locale::Maketext shouldn't be used - we should be
    using Locale::TextDomain instead. I'm considering it for my current needs.

    Any thoughts?

    Regards,
    Andr?

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Stephen Clouse at Oct 6, 2011 at 7:58 pm

    On Thu, Oct 6, 2011 at 11:06 AM, André Walker wrote:

    I don't know if it helps, but I've been researching a little about
    localization recently, and I came across this article:
    http://rassie.org/archives/247

    In summary, it states Locale::Maketext shouldn't be used — we should be
    using Locale::TextDomain instead. I'm considering it for my current needs.

    Any thoughts?
    The article is rather biased -- it points out the speck in Maketext's eye
    while ignoring gettext's planks. The author of the article is so bent on
    how gettext does things that he fails to recognize that at least some of
    what Maketext does is actually an improvement. It reads a lot more like
    "gettext is The One True Way; Maketext is different; therefore, Maketext is
    Considered Harmful".

    gettext was very much built for translating locally-running applications,
    and makes a lot of assumptions that simply aren't true in a web
    environment. One thing about gettext that makes it untenable for web
    applications is its reliance on POSIX setlocale() and environment variables
    to set itself up, a design flaw that Locale::TextDomain tragically
    reproduced to perfection, gauging from the documentation. Take a look at
    these hoops PHP developers jump through to utilize gettext:

    http://fplanque.net/Blog/devblog/2003/08/20/internationalizing_web_applications_usin

    It should induce pain in any sane developer. Hint: if you are having to set
    environment variables halfway through your application to configure
    something, your design is beyond broken. Now, PHP has Zend_Translate to
    rescue them from this horror, but almost no one will utilize it because the
    above kind of cargo-cult hackery is par for the course in PHP.

    Perl has already been rescued from this, hint hint.

    The other thing that really irks me is that Locale::TextDomain hasn't had an
    update since 2009. Open bugs on rt.cpan from 2 years ago. Not a fan of
    such a crucial underlying library being abandonware. Maketext, for all its
    warts, at least still appears to have a maintainer.

    Plus, there are still untapped regions of the l10n universe --
    gender-specific verb endings in Russian, anyone? This is a realm that
    gettext doesn't even begin to address. I have some betting money on which
    system will address it first.

    Now, the article has some valid points about how Maketext does it wrong
    (like not being able to handle a verbatim gettext PO), so let's fix
    Maketext. gettext is a step backwards in the modern Perl world.

    --
    Stephen Clouse <stephenclouse@gmail.com>
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20111006/c34a8bc5/attachment.htm
  • Duncan Garland at Oct 12, 2011 at 1:20 pm
    Now, the article has some valid points about how Maketext does it wrong (like not being able to handle a verbatim gettext PO), so let's fix Maketext.
    Maketext does handle PO files. I know it won’t handle the plurals construct. Is there anything else it trips up on?

    From: Stephen Clouse
    Sent: 06 October 2011 20:59
    To: The elegant MVC web framework
    Subject: Re: [Catalyst] Localisation

    On Thu, Oct 6, 2011 at 11:06 AM, André Walker wrote:
    I don't know if it helps, but I've been researching a little about localization recently, and I came across this article: http://rassie.org/archives/247

    In summary, it states Locale::Maketext shouldn't be used — we should be using Locale::TextDomain instead. I'm considering it for my current needs.

    Any thoughts?

    The article is rather biased -- it points out the speck in Maketext's eye while ignoring gettext's planks. The author of the article is so bent on how gettext does things that he fails to recognize that at least some of what Maketext does is actually an improvement. It reads a lot more like "gettext is The One True Way; Maketext is different; therefore, Maketext is Considered Harmful".

    gettext was very much built for translating locally-running applications, and makes a lot of assumptions that simply aren't true in a web environment. One thing about gettext that makes it untenable for web applications is its reliance on POSIX setlocale() and environment variables to set itself up, a design flaw that Locale::TextDomain tragically reproduced to perfection, gauging from the documentation. Take a look at these hoops PHP developers jump through to utilize gettext:

    http://fplanque.net/Blog/devblog/2003/08/20/internationalizing_web_applications_usin

    It should induce pain in any sane developer. Hint: if you are having to set environment variables halfway through your application to configure something, your design is beyond broken. Now, PHP has Zend_Translate to rescue them from this horror, but almost no one will utilize it because the above kind of cargo-cult hackery is par for the course in PHP.

    Perl has already been rescued from this, hint hint.

    The other thing that really irks me is that Locale::TextDomain hasn't had an update since 2009. Open bugs on rt.cpan from 2 years ago. Not a fan of such a crucial underlying library being abandonware. Maketext, for all its warts, at least still appears to have a maintainer.
    Plus, there are still untapped regions of the l10n universe -- gender-specific verb endings in Russian, anyone? This is a realm that gettext doesn't even begin to address. I have some betting money on which system will address it first.

    Now, the article has some valid points about how Maketext does it wrong (like not being able to handle a verbatim gettext PO), so let's fix Maketext. gettext is a step backwards in the modern Perl world.

    --
    Stephen Clouse <stephenclouse@gmail.com
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20111012/1cb4455e/attachment.htm
  • Peter Edwards at Oct 12, 2011 at 1:52 pm

    On 12 October 2011 14:20, Duncan Garland wrote:

    Now, the article has some valid points about how Maketext does it wrong
    (like not being able to handle a verbatim gettext PO), so let's fix
    Maketext.****

    ** **

    Maketext does handle PO files. I know it won�t handle the plurals
    construct. Is there anything else it trips up on?****

    ** **

    *From:* Stephen Clouse

    **

    On Thu, Oct 6, 2011 at 11:06 AM, Andr� Walker wrote:****

    I don't know if it helps, but I've been researching a little about
    localization recently, and I came across this article:
    http://rassie.org/archives/247

    In summary, it states Locale::Maketext shouldn't be used � we should be
    using Locale::TextDomain instead. I'm considering it for my current needs.

    Any thoughts?****


    The article is rather biased -- it points out the speck in Maketext's eye
    while ignoring gettext's planks.
    Indeed. I used Locale::Maketext
    https://metacpan.org/search?q=locale%3A%3Amaketext
    to handle the translations for 25 different language sites no problem

    e.g.

    search
    http://www.bbc.co.uk/arabic/search/?scope=arabic&q=%D8%A3%D9%88%D8%A8%D8%A7%D9%85%D8%A7

    weather http://www.bbc.co.uk/portuguese/tempo/

    The scenario the author describes about getting your translators to fill out
    the .po file was realistic, although now it is more a case of email around a
    spreadsheet and when it comes back cut and paste the phrases into a .po
    file. It worked well, apart from when I found Myanmar (Burmese) wouldn't
    copy and paste reliably into vi.

    Regards, Peter
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20111012/0eed6606/attachment.htm
  • Stephen Clouse at Oct 12, 2011 at 9:37 pm

    On Wed, Oct 12, 2011 at 8:20 AM, Duncan Garland wrote:

    Now, the article has some valid points about how Maketext does it wrong
    (like not being able to handle a verbatim gettext PO), so let's fix
    Maketext.****

    ** **

    Maketext does handle PO files. I know it won’t handle the plurals
    construct. Is there anything else it trips up on?
    That is mainly what I was referring to, and it is something that Maketext
    needs to do. quant is pretty much useless for its intended purpose, for the
    reasons cited in the article.

    --
    Stephen Clouse <stephenclouse@gmail.com>
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20111012/1766b084/attachment.htm
  • Duncan Garland at Oct 13, 2011 at 8:35 am
    That is mainly what I was referring to, and it is something that Maketext needs to do.
    Agreed. Definitely. The good news is that it doesn’t look like is should be too difficult.

    From: Stephen Clouse
    Sent: 12 October 2011 22:37
    To: The elegant MVC web framework
    Subject: Re: [Catalyst] Localisation
    On Wed, Oct 12, 2011 at 8:20 AM, Duncan Garland wrote:
    Now, the article has some valid points about how Maketext does it wrong (like not being able to handle a verbatim gettext PO), so let's fix Maketext.
    Maketext does handle PO files. I know it won’t handle the plurals construct. Is there anything else it trips up on?

    That is mainly what I was referring to, and it is something that Maketext needs to do. quant is pretty much useless for its intended purpose, for the reasons cited in the article.

    --
    Stephen Clouse <stephenclouse@gmail.com
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20111013/2924899e/attachment.htm
  • Duncan Garland at Oct 18, 2011 at 4:57 pm
    I’ve exchanged emails with Clinton Gormley (Locale::Maketext) and Guido Flohr (Locale::TextDomain). Both are definitely still maintained.

    From: Duncan Garland
    Sent: 13 October 2011 09:36
    To: The elegant MVC web framework
    Subject: RE: [Catalyst] Localisation
    That is mainly what I was referring to, and it is something that Maketext needs to do.
    Agreed. Definitely. The good news is that it doesn’t look like is should be too difficult.

    From: Stephen Clouse
    Sent: 12 October 2011 22:37
    To: The elegant MVC web framework
    Subject: Re: [Catalyst] Localisation
    On Wed, Oct 12, 2011 at 8:20 AM, Duncan Garland wrote:
    Now, the article has some valid points about how Maketext does it wrong (like not being able to handle a verbatim gettext PO), so let's fix Maketext.
    Maketext does handle PO files. I know it won’t handle the plurals construct. Is there anything else it trips up on?

    That is mainly what I was referring to, and it is something that Maketext needs to do. quant is pretty much useless for its intended purpose, for the reasons cited in the article.

    --
    Stephen Clouse <stephenclouse@gmail.com
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20111018/01a506ea/attachment.htm
  • Guido Flohr at Oct 18, 2011 at 11:02 pm
    Hi,

    Duncan Garland pointed me to this discussion. Please don't flame me if
    I missed some obvious points from the previous discussion. Pipermail
    messed up all mails encoded in base64. See for example
    http://lists.scsys.co.uk/pipermail/catalyst/2011-October/027720.html

    I didn't bother to decode them, sorry.

    I am the author of libintl-perl aka Locale::TextDomain, and of the Perl
    backend of GNU gettext. 3-4 years ago I have experimented with
    Catalyst, always with - it's my hobbyhorse, after all - i18n/l10n in
    mind. I haven't touched Catalyst since then; if I missed any recent
    developments, sorry again, and correct me.

    For obvious reasons I used GNU gettext for localisation for these
    experiments, with minimal pain. For the Perl side (model and
    controllers) I just used libintl-perl, and it is a piece of cake, it
    just works. For the views I wrote a plug-in for Template Toolkit which
    exported the gettext API into TT templates. If anybody volunteers to
    maintain that plug-in, drop me a line. I didn't upload it to CPAN
    because I felt that I'm not good enough with TT and Catalyst. But it
    basically works.

    When you endeavour to internationalize a web project nowadays, the
    runtime-aspect is negligible. It doesn't matter how you look up
    translations for messages, even with a gettext implementation without
    contexts or the ngettext plural API, even with catgets. In reality, you
    can always workaround those run-time problems.

    The real problems are:

    1) You must be able to create translation files that are accepted by
    professional translators. Most professional translators for software
    expect formats used by applications for MS-DOS/Windows. More and more
    translators accept PO files. In that other world, where unicorns
    excrete rainbows, sunshine and butterflies, they will also happily
    subclass from your localization handle.

    2) Except for one-shot projects, your translation files should be
    mergeable (mergable?). Portable object (PO) files are pretty much
    mergeable. Some proprietary frameworks maybe offer similiar
    functionality. But I'm only positive for PO files.

    3) In an MVC environment, every translatable message in a model or
    controller is a potential bug or flaw, at least according to yours
    truly. Views are nowadays template based. The challenge is to extract
    messages from your templates. With Perl (Python, Ruby, ...) this is
    actually easy-going because you can usually (ab)use your template
    processor for extracting messages, dump it into a .pot file, (msg)merge
    it with your old po file, and your translators are happy, see 1).

    4) At run-time: GNU gettext selects translations based on the currently
    selected locale, on ?the currently selected locale?. That makes sense
    for desktop applications but not for client-server applications, leave
    alone threaded applications. Switching locale is never thread-safe and
    potentially slow.

    I hope that I will be able to improve the situation a little bit with
    libintl-perl 2.x.

    As far as 4) is concerned, I plan to provide functions that look up
    translations without switching locale. Instead, you can provide the
    name of a language or even the name of a file containing translations.

    The show stoppers are modules/libraries/external applications that use
    the native gettext framework, most notably the system libc. They will
    still select the translation based on the user locale, resulting in ugly
    language mixes, and even uglier charset mixes. Actually, in a web
    application you should strive to hide such messages from the user, for
    usability or merchantability. Yet, this is an open issue.

    For 2), with libintl-perl 2.x you will have functions that can read,
    filter, and write PO (and also MO) files. If you want to gettextize
    your proprietary best-template-system-in-the-world-format files, just
    write an extractor for that format, feed it into
    Locale::Catalog::Format::PO, write a .pot file, and msgmerge it with the
    other .pot files from your project.

    You can follow the progress here:

    git://git.guido-flohr.net/perl/libintl-perl.git
    git://git.guido-flohr.net/perl/pgettext-tools.git

    Check out the POD of lib/Locale/Catalog/Format/PO.pm,
    lib/Locale/Catalog/Format/MO.pm and lib/Locale/Catalog.pm as starters.

    Please don't expect any production code from the above sources before
    the end of the year.

    Guido
    --
    ??????? ??? | Imperia OOD
    ??. ?????-?????-I? ? 86, ????? 1000 | ul. "Knyaz-Boris-I" ? 86, Sofia
    http://www.imperia.bg/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedOct 6, '11 at 12:39p
activeOct 18, '11 at 11:02p
posts13
users6
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase