What is the best way to translate a translation system to a php website?

Question

I am developing a website in PHP and I would like to give the user easy to switch from German to English.

So, a political translation should be considered:

Should I store the data and its translation in a database table ((1, "Hello", "hallo"), (2, "Good morning", "Guten tag"), etc.?

Or should I use .mo files to save them?
Which way is better?
What are the pros and cons?

Answer 1

There are several factors you should consider.

Will the website be updated frequently? if so, by whom? are you or the owner? how much data / information do you mean? and also ... do you often do this (for many clients)?

I can hardly think that using a relational database can lead to any serious speed consequences if you do not have VERY large traffic (several hundred thousand page views per day).

If you often do this (for many clients), do not think further: create a CMS (or use an existing one). If you really need to consider the impact of speed, you can configure it so that when you finish working with the website, you can export static HTML pages where possible.

If you update frequently, the same applies as above. If the client needs to upgrade (not you), then again, you need a CMS. If you are dealing with a lot of information (large and large articles), you need a CMS.

In general, CMS will help you quickly create the structure of your site, quickly add content and not worry about the code, as it will be reused.

Now, if you just need to quickly create a small site, you can easily do this with hard-coded arrays and data files.

Answer 2

After I recently tackled this (12 languages ​​and counted) in a production system and ran into some serious performance issues, I propose a hybrid system.

1) Save the language strings and translations in the database - this will simplify the interaction with the / update / remove elements and will become part of your regular backup routines.

2) Download the languages ​​into flat files on the server and cross them out if necessary to display on the page.

There are many advantages - mostly fast! I am not dealing with communication overhead for MySQL or any traffic slowdown during transmission. (especially important if your database server is not localhost).

It will also make it very easy to use. Store the data from your database in a file as a serialized php and GZIP array so that the contents of the file are reduced due to lack of memory (this also makes it faster in my benchmarking).

Example:

$lang = array( 'hello' => 'Hallo', 'good_morning' => 'Guten Tag', 'logout_message' = > 'We are sorry to see you go, come again!' ); $storage_lang = gzcompress( serialize( $lang ) ); // WRITE THIS INTO A FILE SUCH AS 'my_page.de' 

When the user boots your system for the first time, execute file_exists('/files/languages/my_page.de') . If the file exists, download the contents, un-gzip and un-serialize, and it is ready to go.

Example

 $file_contents = get_contents( 'my_page.de' ); $lang = unserialize( gzuncompress( $file_contents ) ); 

As you can see, you can make caching specific to every page in the system to reduce overhead and use the file extension to indicate the language ... (my_page.en, my_page.de, my_page.fr)

If the file does NOT exist, then query the database, build your array, serialize it, gzip and write the missing file - at the same time, you just created the array that the page needs to continue displaying the page, and everyone is happy.

Finally, it allows you to create update pages that are accessible to non-programmers, but you also control when changes appear, deciding when to delete cache files so that they can be restored by the system.

Warnings and Errors

When I stored everything in the database directly, we hit some BASIC slowdowns when our traffic became spiked.

Trying to keep them in flat file arrays was just such a big problem, because updates were painful and error prone.

Non-gzip, which compresses the contents of cache files, forced language systems to be about 20% slower in my tests.

Make sure that all fields in your database containing languages ​​are set to UTF8-general-ci (or at least one of the UTF8 options, I believe that I use general-ci for most users). If you do not, you will not be able to store non-encoded characters in your database (e.g. Chinese, Japanese, etc.)

Extension: In response to the comment below, be sure to set up database tables with page-level language strings.

 id string page global 1 hello NULL 1 2 good_morning my_page.php 0 

Everything that is displayed in the header or footer may have a global flag that will be requested in each cache file created, otherwise request them on the page for your system to respond.

Answer 3

I also offer the Zend Framework Zend_Translate package .

The guide provides a good overview of how to decide which transition adapter to use . Even if you do not use ZF, this will give you some ideas about what is there and what are the pros and cons.

Adapters for Zend_Translate

• Array
  • Use PHP arrays Small pages;
  • simplest use; only for programmers
• Csv
  • Use comma-delimited files (.csv / .txt)
  • Simple text file format; fast; possible problems with Unicode characters.
• Gettext
  • Use the binaries gettext (* .mo) GNU standard for linux;
  • thread safe; need translation tools
• Ini
  • Use simple ini files (* .ini)
  • Simple text file format; fast; possible problems with Unicode characters.
• TBX
  • Use term exchange files (.tbx / .xml)
  • An industry standard for string application terms; XML format
• Tth
  • Use tmx files (.tmx / .xml)
  • Industry standard translation between applications; XML format human readable
• Qt
  • Use qt linguist files (* .ts)
  • Cross-platform application platform; XML format human readable
• Xliff
  • Use xliff files (.xliff / .xml)
  • A simpler format like TMX, but associated with it; XML format human readable
• Xmltm
  • Use xmltm files (* .xml)
  • Industry standard for memory translation of XML documents; XML format human readable

Answer 4

PHP arrays are the fastest way to load translations. However, you really do not want to update these files manually in the editor. It may work in the beginning and in one or two languages, but when your site grows, it becomes very difficult to maintain.

I advise you to install some simple tables in the database where you keep translations, and create a simple application that allows you to update translations (some forms for adding and updating texts). As for the database: use one table to store translation variables; use another to associate translations with these variables.

Example:

  `text`

 id variable
 1 hello
 2 bye 

  `text_translations`

 id textId language translation
 1 1 en hello
 2 1 de hallo
 3 2 en bye
 4 2 de tschüss 

So what do you do:

• create a variable in the first table

• add translations for it to the second table (in any language you want)

After you have updated the translations, create / update the language file for each language you use:

• select the variables you need and their translation (tip: use English if there is no translation)

• create a large array with all of this, for example:

 $texts = array('hello' => 'hallo', 'bye' => 'tschüss'); 

• write an array to a file, for example:

 file_put_contents('de.php', serialize($texts)); 

• in your PHP / HTML create an array from a file (based on the selected language by the user), for example:

 $texts = unserialize(file_get_contents('de.php')); 

• in your PHP / HTML use variables like:

 <h1><?php echo $texts['hello']; ?></h1> or if you like/enabled PHP short tags: <p><?=$texts['bye'];?></p> 

This setting is very flexible, and with several forms for updating translations it is easy to update your site in several languages.

Answer 5

If you need to provide a web interface for adding / editing translations, then a database is a good idea.

If, however, your translations are static, I would use gettext or even a simple PHP array.

In any case, you can use Zend_Translate.

A small comparison, the first two from the Zend tutorial:

• Regular PHP arrays : small pages; simplest use; only for programmers.
• Gettext : GNU standard for Linux; thread safe; need translation tools.
• Database : dynamic; Worst performance.

Answer 6

I would recommend PHP arrays, they can be built around a GUI for easy access.

Answer 7

Be aware of everyone in the world when you work with a computer, they usually know some common English used on a computer or the Internet, for example, "About Us", "Home", "Send", "Delete", "Read more", etc. .d. Question: Do they really need to be translated?

Well, to be honest, some translation of these words is not really about “compulsory”, it's all about “style”.

Now, if it is really necessary, for ordinary words that do not need to be changed forever, it is better to use the php file, which displays the lang array only for local and English. And for some content, such as a blog, news, and some descriptions, use the database and save as much as you need to translate the language. You must do it manually.

Using and using Google Translate? I think you should think 1000 times. At least for this decade.