Omeka Internationalization

[Jeremy Boggs]

Hi everyone,

We recently created a 'i18n' branch on the Omeka SVN.[1] This is our
first working pass at localization support. It's a branch of the trunk,
and shouldn't be used for production sites.

Here's the rundown of what we've done in the branch:

1) There's a file called Omeka.pot in the root of i18n branch.[2] This
is a PO template, one that can be used to make individual translations.
Check out POEdit for making translations.[3] I went through Omeka to
find as many string as I could for translation. I'm certain I didn't get
them all, but I did get most of them. Help checking this is most
appreciated.

2) Translation files themselves should be put in application/languages.
We have a Spanish translation (es.mo) in there already, based on the
Omeka.pot file mentioned earlier.

3) In application/config/config.ini.changeme, there is a commented-out
option called 'translate.locale'. Add that option to your config.ini,
and set that equal to the name of your .mo file, without the extension.
So, if you'd like to try out the Spanish translation, use this:

translate.locale = "es"

4) Log in to your Omeka admin, and see what got translated.

Work on this will continue until the 1.5 release in the Fall. As I said
before, this is a first pass, one I hope will help get some conversation
started about how best to implement this in Omeka. We're open to
suggestions and changes. A few things we still need to work on:

* Set up a pootle server, or some other web interface where people can
input and download translations. It would likely be better to have a
central repository of translations available for download instead of
including them all in the software's SVN repository.

* Make selecting of locale an option in the site admin, instead of
changing the config.ini file. This would still be site-wide, and not
user-specific.

* Add support for different ways of doing dates. This could either be
determined by the locale itself, or could be a separate option in
settings for formatting dates.

* Add caching for performance.

* Come up with methods for plugins to add translations for their own
content.

If anyone else has ideas about how this can be improved, please share.
And if you have a chance to try this branch out, let us know how it
goes. I'd love to get this whipped into shape to merge back into the
trunk sometime this summer, if not sooner. With your help, I think we
can do it!

Thanks,
Jeremy

[1] https://omeka.org/svn/branches/i18n/
[2] https://omeka.org/svn/branches/i18n/Omeka.pot
[3] http://www.poedit.net/

--
Jeremy Boggs · Associate Director of Research · Center for History and
New Media · George Mason University · chnm.gmu.edu · @clioweb

[Kris Kelly]

Looks great so far.

A few notes / questions:

1) Move the .pot file out of the root and into application/languages/. It'd help to keep all the files related to translation in one place (except cache files).

2) Definitely good idea to run pootle or at least have the .mo files available for download elsewhere, which will ensure that the actual translation work can be kept separate from the release cycle of the core software.

3) One important step that ought to happen is that we should make sure that translatable phrases are worded correctly and consistently. For example, some messages use exclamation points whereas others use periods. No need to standardize it, but the trend should be towards a consistent, easily understood approach. Exception messages are perhaps the most inconsistent tone-wise and may need some work. Also may be good to watch out for might include idiomatic writing that wouldn't necessarily translate well in other languages.

4) What are the advantages to having the locale be an option in the site admin rather than an ini setting?

5) Caching is key to the whole endeavor, otherwise the .mo files will be read and parsed for *every* request. Ideally one would use a fast cache for that, like memcached, but the default for new installations could still be the File cache and it would be much faster than nothing. I'm trying to integrate Zend_Cache_Manager into the core so we can talk about that.

Thanks,
Kris

> --
> You received this message because you are subscribed to the Google Groups "Omeka Dev" group.
> To post to this group, send email to omek...@googlegroups.com.
> To unsubscribe from this group, send email to omeka-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/omeka-dev?hl=en.
>

[sdj loret]

Hi all,

Just to say it's the great great project and i subscribed it now -> translation in french.
Thanks,

Sdj

2011/3/24 Kris Kelly <kristoph...@gmail.com>

[Jeremy Boggs]

On 3/23/11 11:51 PM, Kris Kelly wrote:
> 1) Move the .pot file out of the root and into application/languages/. It'd help to keep all the files related to translation in one place (except cache files).

Putting this file in application/languages caused an error that I
couldn't fix, and honestly didn't spend much time trying to fix since we
won't include this file in the software anyways. We'll remove this file
from the application soon, once we get a service set up for making
translations.

> 2) Definitely good idea to run pootle or at least have the .mo files available for download elsewhere, which will ensure that the actual translation work can be kept separate from the release cycle of the core software.

Agreed. John has already been testing out a Pootle installation to see
if it will work for our needs. We'll be sure to keep this list
up-to-date as we work on that.

> 3) One important step that ought to happen is that we should make sure that translatable phrases are worded correctly and consistently. For example, some messages use exclamation points whereas others use periods. No need to standardize it, but the trend should be towards a consistent, easily understood approach. Exception messages are perhaps the most inconsistent tone-wise and may need some work. Also may be good to watch out for might include idiomatic writing that wouldn't necessarily translate well in other languages.

Also agreed. Will try to do this next week.

> 4) What are the advantages to having the locale be an option in the site admin rather than an ini setting?

The biggest advantage would be ease of changing it, I guess. Having this
configurable from the admin panel would be a requirement, I think, for
Omeka.net, since users don't have access to the config file.

> 5) Caching is key to the whole endeavor, otherwise the .mo files will be read and parsed for *every* request. Ideally one would use a fast cache for that, like memcached, but the default for new installations could still be the File cache and it would be much faster than nothing. I'm trying to integrate Zend_Cache_Manager into the core so we can talk about that.

Sounds great!

Thanks,
Jeremy