[Catalyst] I18N with variables

Ben van Staveren benvanstaveren at gmail.com
Fri Aug 6 15:22:48 GMT 2010


Hi Bill,

Back in the day (heh) we faced the same problem for an app we were doing 
for a client, because the client insisted they wanted the ability to do 
their own translations, we ended up with text keyed on the location 
where it was called from, and the actual english string. So in a 
template we'd get

index.tt2(hello there, customer) as the key, but inside the template it 
was generated by doing [% f.xlat("hello there, customer") %] - or if you 
wanted parameters it was more like [% f.xlat("hello there, %", 
array_of_data) %].

We used one script that would just walk the template directory, and 
would set up the stash like this:

$stash = {
  f => {
    xlat => sub {
      my $string = shift;
      my @params = (@_);
      ...
    },
  },
};

We'd run it, and based on filename and the actual string passed it'd 
generate the "master key file" - some more scripts would look at 
duplicates (e.g. if more than one template contained the same string) 
and would generate a yaml configuration file containing a string => 
template mapping.

Similarly, inside perl modules we used the same mechanism, also 
described this in an earlier reply; where all translation strings *had* 
to be "registered" during module initialisation and it would then dump 
these to it's own master key file.

Rinse, repeat, merge. This then ended up going through the actual 
application's admin interface into the database, where it'd also flag 
everything that required translation into the available languages, so 
that the clients' translator team could go and take care of it.

In the end probably not the most graceful of solutions, and error-wise 
there were a few where certain phrases could have different meanings 
based on context but the code couldn't determine that - but usually that 
got fixed with a little rephrasing in choice locations :)

That's also the system I'm currently using in a slightly modified form 
for the webshop I'm building at the moment. I'll see if I can roll it 
all up into something distributable and put it online for download but 
that will have to happen some time later.


Bill Moseley wrote:
>
>
> On Fri, Aug 6, 2010 at 6:16 AM, Matthias Dietrich <mdietrich at cpan.org 
> <mailto:mdietrich at cpan.org>> wrote:
>
>     I'm using short identifiers for my I18N texts, like
>     "Home.Greeting" which is then translated to "Hi there" for en_us
>     or "Hallöchen" for de_de.  When I added a small CMS to a
>     customer's application all texts should also be translated.  So I
>     saved any text to I18N key CMS.NavigationPoint.PageKey.* within
>     the right language "file" (actually I'm using C::P::I18N::DBI), *
>     for "Title" or "Content" or similar.
>
>
> I've been arguing with work about how to key our text.  So far we 
> continue to use the English in the loc() tags in the templates, and 
> then the I18N team uses a script to pull out this text which gets sent 
> to translation services.
>
> The risk is text gets into the templates that for some reason does not 
> get pulled out.  The developers like the English in the templates as 
> it makes them easy to read, and it means they don't really have to 
> stop when entering new text.  Just seems like in the long run this 
> will be unmaintainable and error prone.  (Well, not in the long run as 
> it already is error prone.)
>
> I've been arguing for a system where we use some kind of ID for the 
> keys.  I'm not so sure the key format matters -- could be just a 
> primary key in the db, for example.  This could be a stage done by the 
> designers so the design spec just indicates a message id.  Then code 
> development and translation can happen at the same time.
>
> Is anyone using a system like that?  And more specifically, what 
> application are you using to manage the translation database?  We have 
> started to write one, but it's a bit more than trivial as we need it 
> to work with different translation services, track history/changes, 
> multiple applications, etc.  So, it would make more sense to use an 
> existing tool.
>
> So, I'd like to hear about your translation workflow and any tools you 
> are using.
>
> Thanks,
>
>
> -- 
> Bill Moseley
> moseley at hank.org <mailto:moseley at hank.org>
> ------------------------------------------------------------------------
>
> _______________________________________________
> List: Catalyst at 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/
>   

-- 
Ben van Staveren
phone: +62 81 70777529
email: benvanstaveren at gmail.com




More information about the Catalyst mailing list