views:

415

answers:

3

I have used GNU Gettext successfully in many projects I have worked in, but at my latest job I have suddenly found myself forced to work with a really awkward localization system.

The current system stores translations in database and adding new translation goes something like this:

  • add function call with translation key to source code, e.g. print translate('foo');
  • add few SQL INSERT statements to translations.sql file.
  • create file with name (current revision nr + 1).sql
  • execute .sql file in database.
  • commit your changes (before somebody else manages to commit and change current revision number).

All this process is completely manual and you have to repeat almost all of it even when you need to fix a small typo. There is no support for plural forms. The whole translations database is quite a mess as translations almost never get deleted from it - only added and updated.

I have tried several arguments to convince other developers (especially one particular dev):

  • I have talked about Gettext being established standard and that there are many tools available for working with PO files.
  • I have tried to explain that storing translations in database has no benefits over storing them to text file - we are just retrieving translations from database by key, nothing more.
  • The other developer is working on PHP part of our app and PHP has Gettext built in. I'm working on JavaScript side, which doesn't have Gettext support, but I have built my own tools for it in the past.
  • Our app isn't so big, that converting from old system to Gettext would take a lot of time even when done manually and I'm quite sure it can be easily automated.
  • I have even successfully used Gettext for one smaller app in our company.

But people still aren't convinced. What might I be doing wrong?

Edit:

A few months after posting this question we are now finally transitioning to Gettext. When we needed to support more than two languages the disadvantages of our current system bacame more apparent to those resisting it so far.

+2  A: 

I can see several options for you:

  • You could try estimating the time (money) saved by using your method.
  • You could show (demo?) how much easier it is to maintain (less headaches).
  • You could go ahead and use the system that is already in place.
chills42
time/money estimate seems like a good idea.
Rene Saarsoo
+4  A: 

What your doing wrong is telling them how to fix a problem that in their mind does not exist.

You need to make them see that it is in fact a problem that needs to be resolved.

Edit:
Glad to see you got there in the end, the second lanuage appears to have made them acknowledge the elephant in the room!

Stevo3000
I think part of the problem is, that I have to deal with 90% of translation problems because I'm working with the UI, while most other developers work with the backend that rarely involves translations.
Rene Saarsoo
@Rene Saarsoo - You could document the proportion of your time spent maintaining the translation. or you could look for a potential flaw in the system to give you more leverage.
Stevo3000
+2  A: 

A few issues might be:

Lack of awareness of Gettext. If the developers don't know about the library they won't use it.

Incompatible licence with GPL. There may be legal reasons why it can't be used.

See no need to rewrite. If the developers are happy enough with the current system then they may see no advantage to moving to Gettext.

Steven
GPL is not a problem - we are using a lot of GPL-ed tools and libs. Lack of awareness clearly is an issue, as I am the only one in the whole team who has used it before.
Rene Saarsoo