Website Localization

[Jumpy09]

Question: What options are there besides "Define" for localization of a website?

 

This is a pretty straight forward question, but I'd like to elaborate simply because I don't like really small posts!

 

For those unfamiliar with the term "Localization", it's when you offer multiple languages which users can toggle through to convert the text you have supplied.  Usually pertains to menus, titles, not encompassing everything like news updates.

 

I had always planned on starting Localization after I got my website past it's beta stages, but I recently found out that define is a bit of a performance hog.  Not memory specifically, but time spent actually defining everything.

 

Currently I use defines for my Database Tables and Fields, if any tables or fields get changed during production it is easier to supply those changes.  Also allows to reuse of any standard scripts which are not specific to any particular website.

 

I found apc_define_constants and hidef, but from what I can tell those would only be plausible uses for Database Tables and such.

 

    - apc_define_constants actually caches an array for constants making it widely available for your scripts (From what I read).

 

An Example:

<?php
$constants = array(
    'ONE'   => 1,
    'TWO'   => 2,
    'THREE' => 3,
);
apc_define_constants('numbers', $constants);
echo ONE, TWO, THREE;
?>

 

    - hidef allows you to set up constants in an ini like file.  It seems to be the quickest method, but it gets parsed when you start your server.  Making it utterly useless for language localization.

 

Example may be like:

int N     = -191
str ABC   = "xyz"
float PIE = 3.1419
bool ART  = true

 

Of course you can go straight up with an assoc array!

 

Example:

<?php
$constants = array(
    'ONE'   => 1,
    'TWO'   => 2,
    'THREE' => 3,
);

echo $constants['ONE']; //1
?>

 

As for hidef I never actually considered adding a slight modifier to the end of a constant, awaiting for a user to toggle it.

 

Example:

<?php
str TITLE = "Silence of the Goats!"
str FR.TITLE = "Silence des chèvres"

$modifier = "FR";    /*Database Value*/ I.e.  FR, EN, AU, RU, DU... ect ect
?>

<title><?php echo $modifier . TITLE; ?> // Silence des chèvres"

 

I suppose that is always a possibility.

 

So what method would you prefer?  Which do you think is easier to maintain?

I figure they all have some type of positives and drawbacks, but anything to get away from define('DOC_ROOT', $_SERVER['DOCUMENT_ROOT']); and it's possible time consuming, bottle necking abilities!

 

Note: Using defines in small scripts isn't much of a problem, I don't believe.  I may even be over-reacting at the time consumption of it.

I would love input!  And let's try to keep this friendly.  Remember we all have what we like to use and what we don't like to use, but that doesn't specifically enable someone the right to force their preferences onto someone else!

 

Thank you!

 

P.S. hidef and apc are PECL and can be found accordingly!

[Fadion]

First question would be: what kind of localization are you referring to? Interface only or database entries too? And why constants?!

 

Just recently finished a website with a massive number of languages. For the interface (static strings) I set up a typical system, with language files in a folder and variables that hold the language files. For example:

 

lang/en.php

<?php
$lang_welcome = 'Welcome to my site';
$lang_bye = 'Sorry to see you go';
?>

 

lang/it.php

<?php
$lang_welcome = 'Benvenuti al nostro sito';
$lang_bye = 'Ciao!';
?>

 

The language files get included, the same variables are used and the rest is history

 

As for the database localization, I'd be glad to see ideas. I've made up a system where there is a "parent" and "language" field in the tables. The default language is added with a parent "0", while translations of that article are added with it's "id" as parent and the appropriate language. It has worked really well for me and it's an intuitive system for my clients, but most probably someone else has got good ideas.

[Jumpy09]

I kind of consider anything that remains the same through everything a constant, a variable that doesn't change.  So your method, I would consider a constant still.

 

I do like it, it is kind of simple and probably would look better than an actual constant.

 

As for Database Localization, that would be kind of fun.  I personally would do something along the lines of multiple tables for different languages.  This could get pretty intensive, but if offering multiple languages for database information there isn't very many options.

 

Either do something like

news_lang_en

news_lang_sp

news_lang_it

 

Post each on individually and depending on the language someone has, pull the content from the individual tables.

 

Another method would be with fields.

table = news

fields = id, user, category, type, title_en, title_sp, title_it, content_en, content_sp, content_it

 

I honestly probably won't be doing DB Localization, and if someone wanted to translate it I would suggest doing it in a comment or something.

 

I understand certain things like News and such would be good to offer in multiple languages, but I was just referring to content such as menu names, and other content that is hard coded into the site.

 

I may eventually set up the news with the individual tables and have translators as admins to post the translated version after I get the original done up the way I want it.

 

What all are you planning on localizing in your database?

[Fadion]

Using different tables or even different fields for database localization works as advertised for very small websites with 2-3 languages and a few tables. Having a site with 5+ languages and 20 tables, you imagine what a hell would it be to manage. To better explain my system of DB localization, I use something similar:

 

Table "News"

----------------

id | parent | language | date | title | content

1 | 0 | en | ... | ... | ...

2 | 1 | fr | ... | ... | ...

3 | 1 | it | ... | ... | ...

 

Basically I have a table that holds an infinite amount of articles and their respective translations. The "language" part is a short code that gets specified when managing active languages and it is unique for each one. In the administration part, the default language articles get shown first with the options to add/edit translations. It has worked really well for me.

 

As for the interface localization, yes those are basically static strings in self-explanatory variables. For a better system that's actually a great solution for big sites, give gettext a try. It's a pretty solid standart for internationalization (i18n), but it is normal to have it's learning curve

[Jumpy09]

Translating anything in the DB hasn't been a major concern.  I just found that define() was pretty slow, and was trying to find ways to do something that will be really quick.

 

I've given hidef a good deal of thought seeing as it'll automatically include the constants, instead of parsing them each time the page is loaded.

 

Only downfall is the constants are completely global across any and every site/program that you use on your server.  But as long as you name everything accordingly giving it a prefix for a specific site, then it wouldn't be too bad.

 

I suppose the parent would really come in handy, and it would allow anyone to translate to whatever they need and expanding languages would be pretty standardized, nothing major needing changed.

 

I may go ahead and add in the potential of translated information in my tables, so that when I get to that point and have a few Translators on hand it will come really easy to go and start adding to it.

 

I have one really big script that is going to be a bit of a hog but it's to help prevent XSS so I believe the performance hit will be well worth it.  So I am trying to find methods of localization that won't eventually also become a bit of a hog.