Helping ordinary people create extraordinary websites!
GET OUR NEWSLETTER
Your Email:
 

Internationalisation and my PHP Development Infrastructure

By Tony Marston
2005-07-17


Design Decisions

While reviewing the possible options I made the following decisions:

  • The idea of running text, whether whole pages or small fragments, through a general-purpose translator was rejected as I have never seen a translation service that produces perfect results. I will therefore stick to the replacement of one string with another as it uses techniques that are tried and tested as well as being fast and accurate.
  • The idea of performing the translation as late as possible, which also implies working on the entire page rather than isolated fragments, was rejected as you don't know what the page may contain therefore you would have to cycle through all the possible substitutions. This would be slow and possibly prone to error if a single word to be substituted also appeared in a group of words which required a different substitution. As I have prior experience of performing the substitution as early as possible (i.e. as soon as it is known what text needs to be output) and with small fragments, which is not only fast but also accurate, I shall stick to the same technique.
  • Next comes the choice between giving each string to be replaced a unique identity or code, or identifying the string by its complete contents. Experience has shown that a mixed approach gives the best of both worlds:
    • Where the string is short, such as 1 or 2 words only, as used in button text or field labels, then it is easier to ignore the use of a separate code and use the whole string as its identifier. For example:
      • The SUBMIT button has an identity of 'submit'.
      • The 'Person Name' field label has an identity of 'Person Name'.
    • Where the string is long, such as in error messages and form titles, then it is easier to use a separate short identifier or code. For example:
      • The form title for each script will use the script name as its identifier.
      • Each error message will be given its own unique identifier, such as 'e1234', and will include the ability to insert runtime values into the output text.
  • As for the choice between the database or non-database files for storing the replacement text, although modern databases can be extremely fast and efficient I also need to be able to give copies of the text in one language to a translation service so that they can be converted into a different language. With a database I would need to have additional procedures to export the data to a medium suitable for transportation to the translation service (which may be situated at a distant location), then import the converted text back into the database. By using non-database files from the start I can eliminate the need for these export and import procedures. Experiments have shown that the use of flat files for this text does not have a significant impact on performance, so it would appear to be an acceptable solution.
  • Shall I put all the language variations in a single file, or have a separate file for each language? Having previously worked on a system where all the language variations were put into a single file, which resulted in a very large and unwieldy file, I decided to have a separate file for each language.
  • Shall I perform the translation within the XSL stylesheet? Although this is a possibility I dismissed it for the following reasons:
    • It would mean performing the translation at a late stage in the proceedings, and I have already opted for an earlier stage.
    • I have no experience of performing these translations with XSL stylesheets whereas I have years of experience of performing then within my application code.
    • I am unsure of the performance impact with XSL translations, whereas my existing methods have no noticeable impact.
    • At some point in the future I may want to produce the output without using XSL, in which case I would require a non-XSL translation facility anyway.


Tutorial Pages:
» Introduction
» Possible Methods
» Design Decisions
» My Implementation - Directory Structure
» My Implementation - File Names
» My Implementation - Determine User Language
» My Implementation - Locate Language Subdirectory
» My Implementation - Load Screen Structure file
» My Implementation - Get Language Text
» My Implementation - Get Language Array
» My Implementation - Handling Dates
» My Implementation - Handling Numbers
» Conclusion
» References


 | Bookmark
Related Tutorials:
» Port Scanning and Service Status Checking in PHP
» Web Database Access from Desktop Applications
» CubeCart 3.0 Installation and Configuration
» PHP Site Search Made Easy
» Installing and Configuring Drupal 6.1
» Desktop Application Development with PHP-GTK

Advertise with Us!


Tutorials Scripts Web Hosting Developer Manuals
Resources