[eluser]esra[/eluser]
[quote author="Negligence" date="1198199409"]In my experience with translations, I have not sent off the actual PHP file containing the language strings. All the strings are put into Word, then sent off for translation. When it comes back in this format, it's easy to do the copy/paste into a single file. Most translators I've worked with do not know anything about code, so we don't give them a sight of it, however simply it may be.
As for the modularity, the only reason why it isn't modular (for you) is because you're sending code to the translators. I've never heard of this being done, hence the reason why the library doesn't account for that kind of situation.[/quote]
In any case, your approach should prove useful to many CodeIgniter users. If you are handling translations on your own as a developer, fine. But if you are not, my aguments may be valid.
Sending translations out to professionals is pretty much standard for any software company or business who deals with language translations on a day-to-day basis, especially companies who target products to a global customer base. In the U.S and abroad, there are thousands of companies who handle this need. Most software houses or businesses sooner or later hire a part time or full time administrator to handle this sort of thing. If not, it takes a lot of time away from developers and is not very economical when you consider the hourly rates or salaries paid to a programmer versus an administrator.
I usually bounce our translations on our sales representative for a specific locale. They are usually a good indicator as to whether a translation was successful or not.
Generally, experienced translators who make a living in this field are a smart lot. They are accustomed to working with or converting the string handlers for numerous programming languages. Numerous approaches are also used within the same programming language to achieve the same goals. Many translators are also accustomed to working directly with database content. They have their own bag of tricks for placing language strings in a generic format used by their language translation software/machines. If not, they usually have access to someone who can place the strings into a format that their software can read.
Translations are generally very locale specific because they have to be. The Portuguese spoken and written in Portugal is in many cases different from the Portuguese spoken and written in Brazil. Over the years, the various dialects of a language tend to change within a given geographic locale. I believe that there are over 40 different dialects of the Spanish language and a larger number of Arabic dialects and most have become locale specific over the years. If I'm targeting Brazil as a potential software customer audience, you can bet that I'm going to request a translator who has experience writing translations for that specific locale. If the same product is being targeted at Portugal, a separate translator may be employed for that particular translation. Unless in a rare case, you find someone with spoken and written language skills for multiple locales.
The default language for Language.php for my CodeIgniter builds has been changed to en_US for this reason, making it possible to support en_GB, en_AU, en_NZ, etc. or using the above example, pt_PT, pt_BZ, etc. This allows language translations to be fine tuned for specific locales. My language directories for system/language/ and application/language/ use the same directory naming syntax rather than language names. This approach is pretty typical and closely follows W3C i18n recommendations. You might note that Kohana took a similar approach in 2.0 as well as other i18n improvements (e.g., support for UTF-8/Unicode string handlers).
It's not modular because the approach is not modular and loosely coupled in an OOP sense.
