views:

50

answers:

3

I'm looking to i18n-ize a web app. The site will be constantly changing: text will be rewritten, new stuff added etc. The web app is written in PHP, but the same applies to any language.

Basically I want:

1) The code to be readable and maintainable 2) Translators to be sent an email when new stuff is added in English OR the English is changed 3) To know whether something is up-to-date or not. 4) Translators be able to update things online

I guess the best idea is to store everything in a database and handle things that way rtaher than PO files and gettext. But what's the best way:

$lang('contactus') has the disadvantage of being unreadable (code-wise), and slower to develop (as all English needs to be given a unique key and stored in the database)

$lang('Please contact us for more information') is readable and quicker, but if the English changes (typo, grammar edit, updated) then the translation disappears entirely.

How do other apps/frameworks handle it?

+1  A: 

Avoid storing strings that need to be translated in the database. Did that myself and regretted it. Use external files that you can send to translators. Use strings in your preferred language as the keys. So as for your example $lang('Please contact us for more information') is the way to go. A text change in the English probably means a corresponding change in the translations so yeah it's a maintenance headache.

Plus there's more to it than just string translations. There are currency symbols and formats, number formats (decimal, digit grouping symbols, where the symbol appears), date formatting. Name formatting - in some locales people often have middle names in others they usually don't. Text reading left to right vs right to left as well. ugh.

For a web app it's sometimes just much simpler to have the web pages separated into language-locale directories and deal with it that way. You do have all you business logic separate from the view code right? This is where embedding business logic directly within html ala the typical PHP approach really starts to hurt.

Khorkrak
instead of `$lang['Please contact us for more information']`, why not use something like `'contact_us_msg'` as the key, which then retrieves that whole string? It means you don't have to maintain two (or many many more) instances of that entry.
nickf
Could you just clarify why you regretted using a database? The reason why it seems a db project for me is that I'm probably going to want translators (in reality people who work in our regional offices) to provide translations and updates on a regular (weekly) basis. It's pretty essential to have them update things through our website, rather than a workflow where twenty untrained people without specialist software are emailed PO files every 5 days and then we get them back by dribs and drabs.
Apemantus
(I know I could still get them to edit a file via web ui, but there's other benefits like date modified etc)
Apemantus
+1  A: 

Make some translation function with an easy to type name, for example t($key) or use existing solution (for example Zend_Translate) or PHP gettext, that provides the _($key) function.

The format of your translation files should not matter so much - whatever fits your translation process best.

Use your original language, for example English, for the key. For longer strings it makes sometimes sense to invent artificial keys, for example "introduction_text_1"

Alex
A: 

Never use constants or any shortened translation keys, don't use the database, avoid using just arrays. The only professional way to handle translations is a gettext(-like) function.

You should only use _("Original english text queries"). This has the advantage that at least the default language text is still available, should translation data/files be inaccessible.
Don't worry about changes in the text strings. In reality this is rare. If you use the gettext syntax, there are even tools to adapt the language files automatically then. Not many good tools, mind you. But more than for homebrew translation methods, and it gets the job done. If your PHP interpreter doesn't support native gettext, search for the "php-gettext" emulation or "upgradephp".

mario