Fork me on GitHub
Subscribe 2

Ticket #367 (fixed enhancement)

Add new translation system

  • Created: 2011-03-20 20:57:11
  • Reported by: Reines
  • Assigned to: Franz
  • Milestone: 2.0-alpha1
  • Component: localization
  • Priority: high

We have decided on gettext for translations, however we cannot rely on PHPs implementation because it is not included in all PHP installs.

I think the most suitable implementation I've found is PHP-Gettext. We should fork this to fluxbb/gettext and add it to FluxBB.

History

Franz 2011-04-06 12:12:34

  • Owner set to Franz.

Oh yes, I'm very much interested in this. What's the plan? Use the Gettext library directly or wrap it into a utility class for loading language files and retrieving translated strings?

Reines 2011-04-06 16:02:47

Well the Gettext::parse function can be used to parse a .mo file into an associative array, which gets us to same point we have at the moment but using gettext rather than PHP files.

The next issue is how we want to wrap this up. In this case dependencies might be more of a problem, since both the frontend and API will need access to the translation features. This gives us 4 options really:

  1. Have the API and front end load their own language objects separately. At first consideration this seems kinda stupid, but actually it might be a nice way to separate the strings anyway (so instead of having separate files for profile/viewtopic/etc we would have api.mo and frontend.mo files).

  2. Have the language object created as part of the API, and the front end access it via the API. This would work, but really translations aren't the job of an API, so from an organizational point of view this doesn't make much sense.

  3. Have the language object created as part of the front end, and passed to the API. This would make a bit more sense from an organizational point of view, but until the API is loaded we don't know which language to use...

  4. The other option is to avoid the use of OOP, and simply have a __() function with a global $lang variable which can obviously be called from either the front end or the API.

In the case of 1-3 we would probably want to change the Gettext class to not be static, so we could do something along the lines of:

$lang = new Gettext('api.mo');
echo $lang->t('Hello world');

My vote would probably go for option 1 here I think.

Franz 2011-04-23 08:13:09

I would prefer code like this:

$lang->load('common');
$lang->load('admin/common');
$lang->load('admin/users');

echo $lang->t('Forum index'); // String from common
echo $lang->t('Admin title'); // String from admin/common
echo $lang->t('Administer your users'); // String from admin/users

Should I add this code to the Gettext class or have another wrapper class?

Reines 2011-04-23 10:11:04

Just change the Gettext class. Though how do we want to handle the dependencies? If we're using (1) from above then we'd just have $lang->load('api.mo') and $lang->load('frontend.mo') (though the underlying code would be the same).

Franz 2011-08-13 20:52:26

I've been working on this a little.

As far as I remember, we wanted to cache the values, right? Maybe it would be better to do the loading, accessing and caching in another class, that only uses the Gettext class when necessary. What do you think?

Franz 2011-09-15 21:18:47

Commit 6b74c31 to fluxbb fluxbb-2.0

#367: First attempt at a class for the new translation system.

Franz 2011-09-16 02:53:30

I have created another wrapper class now. It's much cleaner that way.

Pull request.

Franz 2011-09-19 14:31:01

Commit 664cb8b to fluxbb fluxbb-2.0

#367: Add Gettext file common.po (and .mo, too) and use that in all the core files.

Franz 2011-09-19 21:44:02

Commit 2aa7af9 to fluxbb fluxbb-2.0

Merge pull request #21 from lie2815/fluxbb-2.0-gettext

#367: Start of a new translation system.

Franz 2011-09-21 22:06:58

  • Status changed from open to fixed.

This is done - we will handle the rest in other tickets.