Your opinion on best language file practise?

[P Pulkkinen]

Hi all, I am in a php development project and I would like to hear your
opinions on language file practises.

1) One huge or many small?
=============== =============== ======
Currently we have one big per language, like en.php or fi.php. Since I
expect this app to grow, I have started to think we should have different
file for every output page or widget in the application.


2) "Best" syntax
=============== =============== ======

Currently every language file is an associative array like this:

<?php
$lang = array (
"push_this" = "Push this",
"push_that" = "Push that"
);
?>

So the keys are as descriptive as possible to ease up the work of
translators. Since only one language file gets included, only one
$lang-array exist in global namespace. Some use just generic keys like
"expr_234" = "Push that" but they are not very descriptive.

It could also be possible to use typical configuration syntax (one key and
value per line)

push_this = "Push this"
push_that = "Push that"

which would not be php, but then some functions would read the file and
turn the content into an array.

3) Or, have someone found a database to be better for some reason
=============== =============== =============== ==
I don't remember any case from apps I have downloaded, but
I wouldn't be surprised if SOMEONE somewhere prefers
this solution.

So, now your opinions and experiences :-) This is not an
"i-have-a-huge-problem"-issue, but just part of every coders everlasting
quest to find the best practises :-)

[Michael Fesser]

Re: Your opinion on best language file practise?

..oO(P Pulkkinen)

>Hi all, I am in a php development project and I would like to hear your
>opinions on language file practises.
>
>1) One huge or many small?
>============== =============== =======
>[...]
>2) "Best" syntax
>============== =============== =======
>[...]

My framework is prepared for handling multilingual content. It's not
fully implemented yet, but the backend will most likely be the gettext
extension. I've worked with it in the past and like it.

>3) Or, have someone found a database to be better for some reason
>============== =============== =============== ===
>I don't remember any case from apps I have downloaded, but
>I wouldn't be surprised if SOMEONE somewhere prefers
>this solution.

I also do that, because some parts of the content come from a DB. In my
framework every multilingual table consists of two "physical" tables in
the DB, e.g.

events
eventsI18n
products
productsI18n
sitemap
sitemapI18n
....

The main tables contain all the generic informations like record IDs,
related records in the same or in other tables, dates, prices etc. The
I18n tables hold all the language-specific informations, with one record
per language. Their primary key consists of the record ID, which also
references the record in the main table, and a 'lang' column, containing
a 5-char language code (de-DE for example).

Micha

[P Pulkkinen]

Re: Your opinion on best language file practise?


"Michael Fesser" <netizen@gmx.de wroite

>
My framework is prepared for handling multilingual content. It's not
fully implemented yet, but the backend will most likely be the gettext
extension. I've worked with it in the past and like it.

Is your framework open source :-)

I also do that, because some parts of the content come from a DB. In my
framework every multilingual table consists of two "physical" tables in
the DB, e.g.

Thanks. Outside of language thing, I would like to know, how this kinf of
sister tables are declared in mysql. Or do you just manually keep their
indexing in harmony, removing and inserting records at the same time to both
tables. I ask this, because somethimes this kind of need rises up. For
example, I could like to have a very minimalistic users-table and then have
additional sister tables that are related to some specific installation or
some extra module.

[Michael Fesser]

Re: Your opinion on best language file practise?

..oO(P Pulkkinen)

>"Michael Fesser" <netizen@gmx.de wroite

>>
>My framework is prepared for handling multilingual content. It's not
>fully implemented yet, but the backend will most likely be the gettext
>extension. I've worked with it in the past and like it.

>
>Is your framework open source :-)

Nope. It's just for private use and my personal "playground ". I already
use it on some small production sites, but some parts of it are still
experimental or not fully implemented.

>I also do that, because some parts of the content come from a DB. In my
>framework every multilingual table consists of two "physical" tables in
>the DB, e.g.

>
>Thanks. Outside of language thing, I would like to know, how this kinf of
>sister tables are declared in mysql. Or do you just manually keep their
>indexing in harmony, removing and inserting records at the same time to both
>tables.

Removing and updating records can be handled by the DB itself, using
FOREIGN KEY constraints (I can post an example if necessary). Inserting
new records requires a bit more action, but is usually done with a
script, not by hand.

>I ask this, because somethimes this kind of need rises up. For
>example, I could like to have a very minimalistic users-table and then have
>additional sister tables that are related to some specific installation or
>some extra module.

You can define what should happen in the sister tables if something in
the main table is changed or removed (in MySQL this requires the InnoDB
storage engine):

CREATE TABLE sisterTable (
...
FOREIGN KEY (recordId)
REFERENCES mainTable (recordId)
ON UPDATE CASCADE
ON DELETE CASCADE
) ENGINE=InnoDB;

Micha

[Rik]

Re: Your opinion on best language file practise?

Michael Fesser <netizen@gmx.de wrote:

>Thanks. Outside of language thing, I would like to know, how this kinf
>of
>sister tables are declared in mysql. Or do you just manually keep their
>indexing in harmony, removing and inserting records at the same time to
>both
>tables.

>
Removing and updating records can be handled by the DB itself, using
FOREIGN KEY constraints (I can post an example if necessary). Inserting
new records requires a bit more action, but is usually done with a
script, not by hand.

Foreign keys indeed rock. And as translations will always have to be
entered by a human having a seperate code for this is no bother.

I usually define a 'fallback' (usually english) in the normal table, with
a simple LEFT JOIN on the translations, and
IFNULL(translat ions.field,norm al_table.field) statement. Can seem ugly for
foreign users, a portion of untranslated text, but this way I can leave it
up to the client to decide to either have an empty text (in which case it
won't be NULL) or the fallback.
--
Rik Wasmus