/ 
Catalyst-Plugin-I18N-DBIC-0.04
River stage zero No dependents
/ Catalyst::Plugin::I18N::DBIC

NAME

Catalyst::Plugin::I18N::DBIC - Internationalization for Catalyst, data loaded from database

SYNOPSIS

use Catalyst qw(-Debug I18N::DBIC);

__PACKAGE__->config(
    name => 'MyApp',
    'I18N::DBIC'    => {
        lexicon_model   => 'DBIC::MyLexicon',
    },
);

You can load the lexicon in your controller.

$c->languages( ['de'] );
$c->load_lexicon( qw(footer header user/list navigation) );
print $c->localize('Hello Catalyst');

Or in your template

[% c.load_lexicon('header', 'navigation') %]

[% c.loc('Home Page') %]
[% c.loc('Welcome to Catalyst') %]

DESCRIPTION

This module is based on Catalyst::Plugin::I18N and I18N and you should refer to those modules for further information.

These modules hold their localization data in files (mo, po or pm files) and for a very large application these files can become very large and difficult to maintain.

Catalyst::Plugin::I18N::DBIC however allows you to hold the localization data in a database (using Catalyst::Model::DBIC::Schema ) which has several advantages.

  • The localization data can be split into several 'paths' which represent the natural organization of the application. e.g. 'footer', 'header', 'navigation', 'user/list'.

  • You can write an application that directly modifies the database so that your translators can do their stuff more easily and directly.

  • If you have a client that requires custom text it is easier to do this by making a database change than by releasing a new text file.

EXTENDED METHODS

load_lexicon

Takes an array of 'paths' which should be searched to load the Lexicon data from the database.

It is more efficient in database requests to request all paths that may be used on a page in one go. It may however be more convenient to make several requests if you include templates in other templates (such as header and footer templates) and make separate calls in each template.

Database Schema

The module requires a table called lexicon with the following structure

CREATE TABLE lexicon (
  id          int(11) NOT NULL auto_increment,
  language    varchar(15)     default NULL,
  path        varchar(255)    default NULL,
  message     text,
  value       text,
  notes       text,
  PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

By default the table lexicon is used if you don't specify the lexicon_model in the config. If you use an alternative table you must still use the same structure.

Actually you may want to change the index method and the 'notes' field is not required but can be useful to hold information to help the translator put the message in context.

The value is the tranlated message. The path is the context where the message is used. For example you may wish to group all the menu button text and navigation text into the navigation path. All the text for the generic header template could be in the header path etc.

SEE ALSO

Refer to Catalyst::Plugin::I18N for information on the other methods used.

TO-DO

Implement caching methods on-demand or pre-load =item Reduce name clashes for text by making use of the path data

AUTHOR

Ian Docherty, cpan@iandocherty.com

With thanks to Kazuma Shiraiwa, Brian Cassidy and others for feedback and advice.

COPYRIGHT & LICENSE

Copyright (c) 2005 the aforementioned authors. All rights
reserved. This program is free software; you can redistribute
it and/or modify it under the same terms as Perl itself.