Internationalization: Converting to PHP Gettext

You have that flexibility with PHP gettext. You can, if you like, split your strings into different translation files. And on some really big apps it could make sense to have 2 or 3 different translation files for the major sections of the app. PHP gettext is completely configurable to do any of these things. But my recommendation for something like OC which only has a few hundred strings and not many many thousands, is to keep it to just ONE file for the cart. And as far as 3PD, each vendor should have ONE translation file that OC can register and use for the vendors packaged mods.

You should read the docs on PHP gettext and also at GNU gettext. You would see just how powerful and flexible the gettext system is. It can be as simple or as complex as needs demand.
http://www.php.net/manual/en/ref.gettext.php
http://www.gnu.org/software/gettext/manual/gettext.html



.

To help people appreciate the power and ease of using PHP gettext I prepared a little example app.

Unzip it somewhere under your docroot on a webserver and access it like:
http://YOURDOMAIN/WHEREYOUPUTTHEAPP/php ... ainapp.php

The example has a Main App as well as a Vendor Mod.

I think this will give you the idea of how easy it is to use PHP gettext.

Enjoy.


.

There seems to be some confusions about the gettext format.
In a nutshell, if you ever worked with wordpress, you should know about it. If not, view it as a better system to store localization strings in a centralized location for your app.
In the simplest form to make, edit a translation file in gettext format one could use Poedit, a very nice open source program for windows.
I do know a thing or two about translating web apps, because i did quite a few over the years for various systems, including opencart, drupal, prestashop, wordpress, tomatocart, magento, cmsms etc.
One very nice feature of the gettext is that you could use proper plural forms automatically (romanian has 3 forms, one for 1 singular and 2 forms of plural, and the php-file way of managing that is non existent ). Proper character sets for each language is another strong point.
I don't say that he actual opencart system is a bad one, all I say is that is not the only or the best way to do translations. Think of all the duplicate strings and that you want to modify one. Right now you should go through each file in a translation to be sure, with gettext you simply update the string once.

Sorry if my english is not quite fluent, not a native speaker.

still seems like rather a big pain to me as a module maker what happens when I make a mod if you are using gettext do you have to download my language files after you install my mod to a local server and run the script mentioned before on them for them to work? I just can't see the average user being able to figure out having to install a local copy of gettext and running any kind of script. I don't even fully understand it from the descriptions given it just seems like too big of a pain for me to even bother, so I can't imagine what a average joe user would think.

IF your main language is English and your shop will only be in English, I can only think of 1 reason to use this and that would be not having to declate "text_home" in multiple files. However, it seems that this pain in the arse will be less of a pain with 1.5 it seems.

However, for opencart in general, using Gettext or other translation friendly format would be beneficial. Once again, this is going to depend on what 1.5 brings us. But even with easy to declare text variables there is still the need to help non-English speaking users to:
- save time,
- provide R->L or L->R reading ability (Thank goodness we don't have to worry about Chinese and Japanese UP -> Down L->R reading patterns -- Yes, they do starting reading from the top right going down and work towards to the last word that is located on the bottom left. The Japanese would say that you are reading your book or magazine starting on the wrong page even (they from an English speakers point of view start at the back of the book)
- allow pluralizations or non-existence of
- deal with the Mr. Mrs. Miss, etc issue
- el, la (spanish) and other noun declaration issues
- and a few other minor but yet can be major for such and such language.

IF your native is NOT English, imagine how the other 80% of non-English speaking average Joes would think of not having easy acces to their own language.
Just for reference: http://www.vistawide.com/languages/top_30_languages.htm
English is 20% of the world however include non-official and able to use at a conversational level you would have somewhere between 35-50% but subtract out most of Japan and non-readable people you'd be close to 35-40%.

Yeah, I know how the US loves to believe they are the center of the Universe, we Americans still need to remember that we only control the Internet Universe unless some other control highjacks a router here or there

Xsecrets wrote:...what happens when I make a mod if you are using gettext do you have to download my language files after you install my mod to a local server and run the script mentioned before on them for them to work?

I think if you took a few minutes and actually began playing around with gettext you would begin to understand just how easy it makes things.

To answer your question, when you make a mod you can include whatever translations you would like to provide. Or you can provide none for that matter and just provide the basic english .po file which has all the translatable strings from your mod.

Then either the user or a translator or anyone can separately provide additional translations because they can just create a new language directory under 'locale' area and put their translations in the .po in that new directory and then run 'msgfmt' and now there is a new translation available for your mod.

As I say this is all very simple. If you worked with it for a few hours you would see the power and ease of using gettext.


.

I still don't think you get it people can't figure out how to upload files with ftp they are never going to figure out how to simply run msgfmt whatever that is whatever they have to do to get it installed on their local computer to actually run it. Sounds to me like using this would make any external mods pretty much out of the possibility of use for 90% of the people.

Xsecrets, your assertion about users not knowing ftp will prevent them from installing translations doesn't hold water.

If people are smart enough to figure out how to install your mod, then they are smart enough to figure out how to install a translation update for a mod.

What do you think happens right now with the current translation system? Users install translations.

It would be no different using gettext.

And users will not normally be the ones creating new gettext translations. That will usually be either the mod-provider or a third-party that deals in creating translations. They will create new translations and package them up for users to install. But also, with gettext a user with half-a-clue can also create translations for themselves if they can run a few commands and do know how to ftp.

And if you'll take the time as I said to familiarize yourself with gettext you would see that it is a much more powerful translation system.

Gettext has far more capabilities than any home-grown translation system. It can handle every language, plurals, dialects, etc.

.


.

greno wrote: What do you think happens right now with the current translation system? Users install translations.

It would be no different using gettext.

That's fine for the users that have to create a translation, but from the way I'm understanding it all the english speaking users will have to do several extra steps just to get the language data in where right now they just upload and go.

Xsecrets wrote:... but from the way I'm understanding it all the english speaking users will have to do several extra steps just to get the language data in where right now they just upload and go.

Well quite frankly I don't think you understand hardly anything yet about gettext. You just keep making uninformed comments based on assumptions that are entirely wrong.

To use the basic OC with gettext users do not have to do ANYTHING. English speaking or otherwise.

OC using gettext would come with the basic english files already installed. And the same would be true for mods using gettext. They would come with the basic english files.

If users want translations they can either do them themselves if they know how to run a few commands and can ftp to their host otherwise mod-providers or third-parties can package and sell/distribute gettext translations which users can install.


.

phpget text is a php extension. I doubt every server that people install opencart on will have this extension installed. the current way is the best and there is nothing wrong with it. php is very flexiable alot more felxibility then you would get using a 3rd language.

Daniel wrote:phpget text is a php extension.

On any major distro I have not seen yet a version of PHP that did not have gettext support. That would be like totally ignoring the entire international community and the large number of applications that use gettext translations.

I just did a quick check of about a dozen servers and every one of them, some old, some very new, had gettext support in the PHP distro package:
$ php -i | grep -i gettext
gettext
GetText Support => enabled

They all reported this. So I don't think there is any issue with relying upon gettext being available.

In addition if you will take the time to look carefully at how I implemented this, it leaves the current translation system in place and gettext becomes a second pluggable-could-be translation system. There would need to be some minor changes made to make it pluggable but then OC could offer users a choice of translation systems.


.

I opened up the file structure for opencart 0.8 and realized how far opencart has come since then especially in file organization.

Daniel,
I'm going to agree with you on reasons for not using get_text however, I truly, believe that the current situation should change.

After spending more than a month now, about 3-6 hours a day, with opencart code I've come to the conclusion that the language files are a great place to litter. Also, templates since you end up coming up with your own naming conventions and such. On top of which, I need to redeclare lots of language declarations for no reason besides that fact that they belong to a different module.

Are you going to consider a different path to take once 1.5 comes out?

SapporoGuy wrote:I opened up the file structure for opencart 0.8 and realized how far opencart has come since then especially in file organization.

Daniel,
I'm going to agree with you on reasons for not using get_text however, I truly, believe that the current situation should change.

After spending more than a month now, about 3-6 hours a day, with opencart code I've come to the conclusion that the language files are a great place to litter. Also, templates since you end up coming up with your own naming conventions and such. On top of which, I need to redeclare lots of language declarations for no reason besides that fact that they belong to a different module.

Are you going to consider a different path to take once 1.5 comes out?

so you would want what one giant file with 10,000 definitions in it? and every single module written by anyone has to modify that one file? sounds like a recipe for disaster to me.

I agree with you, that would be ridiculous. So, actually, no.
However, the current situation is not much better if you are taking about a disaster waiting to happen. Either way something does need to be considered.

At the moment, I have been playing with: I'm still not keen on that since you still have to add to the controller the variables for which text to use. Given, Daniel did say that this will change in 1.5; so I'll leave that as a comment only statement.

What I'm doing above is not optimal either since it is loading extra files and creating over head that will build up eventually.

I'm thinking at the moment:
- 1 major file that contains only the necessary cart words. Words that "every" cart basically uses
- smaller files for a per page basis, these will also allow the developer to enjoy their freedom
- added DRY'ness
- # will be a pain for developers to keep track of what is already in use. However, it is like APIs which you need to be familiar with anyways to prevent double coding.

This will help when you want to move stuff from the header to the footer and such. This will also help with the 4 zones for modules that is being talked about for 1.5.


X,
Why are you such a fan for the current setup? I can see why you don't like what is being suggested but do you really think that the current situation is that good that it doesn't need improvement?

SapporoGuy wrote:I agree with you, that would be ridiculous. So, actually, no.
However, the current situation is not much better if you are taking about a disaster waiting to happen. Either way something does need to be considered.

At the moment, I have been playing with:

Code: Select all

$this->language->load('module/account');
// extra modules
$this->language->load('common/header');
$this->language->load('account/login');

I'm still not keen on that since you still have to add to the controller the variables for which text to use. Given, Daniel did say that this will change in 1.5; so I'll leave that as a comment only statement.

if you have new text that needs defined in a module you simply create a language file for that module and load it there. I don't see the problem you are describing as there is an overall language.php file for text that is universal in the cart.

What I'm doing above is not optimal either since it is loading extra files and creating over head that will build up eventually.

I'm thinking at the moment:
- 1 major file that contains only the necessary cart words. Words that "every" cart basically uses

sounds like the way it is.

- smaller files for a per page basis, these will also allow the developer to enjoy their freedom

sounds like the way it is.

- added DRY'ness

no idea what DRY'ness is.

- # will be a pain for developers to keep track of what is already in use. However, it is like APIs which you need to be familiar with anyways to prevent double coding.

Don't really see it being that big of deal are we really worried about a couple of bytes here and there.

This will help when you want to move stuff from the header to the footer and such. This will also help with the 4 zones for modules that is being talked about for 1.5.

module have their own language files which gets loaded with the module. Doesn't matter where the module is located, so I'm not seeing the problem.

X,
Why are you such a fan for the current setup? I can see why you don't like what is being suggested but do you really think that the current situation is that good that it doesn't need improvement?

it's not that I'm a huge fan I just don't see it as a big problem. It all seems pretty logical to me. I will be happy when it gets changed so that you don't have to redeclare the variable in the controller needlessly, but that is supposed to get fixed anyways.

Fair enough

I am not gonna go on about this, so I guess I'm gonna wait till 1.5 ... and make another decision then.
I still think that things could be slightly differently and I'm not really sure why myself either besides having this spidy sense that this is not really the way to go.

Dry'ness ::: lolo, created that one ... It really should be DRY as in the DRY principle (Don't Repeat Yourself) this is really big in the Ruby world and even in the Python world. The PHP world still has a fair ways to go in regards to a more modern approach to coding.

I know this post is ages ago... but this method (in terms of translations) could be a great thing for OC.
Translations could be done faster and better.
Also some variables are repeated on different files, with one translation file it wouldn't happen.

greno wrote:A cart is a perfect usage for PHP gettext.
Look at how many different strings need to be translated in the cart. It's hundreds!
And having all the translations in ONE file makes the translators job very easy. I know, I've been doing this for years.
About how to make doing translations easier: find good translators that will help you.

Yes, one file could make life easier for translators. Specially on every new update of OC, every time i've to check all folders and files one by one, because automated software doesn't help because of translated text itself...

Xsecrets wrote:still seems like rather a big pain to me as a module maker what happens when I make a mod if you are using gettext do you have to download my language files after you install my mod to a local server and run the script mentioned before on them for them to work? I just can't see the average user being able to figure out having to install a local copy of gettext and running any kind of script. I don't even fully understand it from the descriptions given it just seems like too big of a pain for me to even bother, so I can't imagine what a average joe user would think.

Simply make your module and update the language file, so translators could make the translation of your module also.
Your module will need translation instead of the method OC uses for translations.