Google Groups

RE: [silverstripe-dev] _t() and in 3.0

Quirk Nov 21, 2011 3:01 AM
Posted in group: SilverStripe Core Development



Just like to give my input on translations.


We’ve made translation module which enabled in context editing as well as editing translations in a list view. I haven’t been able to publish it as a proper module since it contains a few kinks such as:

·         Copying the cached templates but with rewritten versions  of _t calls (with input capabilities to enable in site editing) to a new directory

·         Selecting said directory when admin user is performing in site translations editing

·         Requiring a _ss_environment.php file to do above mentioned switch


Previously we saved any changes directly into the lang files. This was a horrible mistake since it means that any changes made live would be overwritten on a new deploy, or it would require keeping the live lang files while deploying and putting them back when you’re done.


The approach we’re doing now is to store any changes in the database and then add the ability to import, export to and from the database.

Also we’re hooking into controller onBeforeInit to overwrite the lang values with any changes from the database enabling translations edited live to be shown instantly.


Is there any noticeable performance impact from using yml instead of the php lang files? We’re having performance issues as it is and would like to avoid more of them J


Best Regards


Daniel Lindkvist


From: [] On Behalf Of Ingo Schommer
Sent: den 18 november 2011 16:49
Subject: [silverstripe-dev] _t() and in 3.0


Hello there!


As we're developing more of the 3.0 UI, we also need to start thinking about

the required translation effort. At the moment we're in a bind where the 

new translation strings can't be imported easily to without 

cutting off the ability to safely export those translations to 2.4 again.


There's certain hacks around this which I'm looking at on the short term,

but in general I don't think the project has a future.

I've asked for maintenance help numerous times on this list, with little feedback.

The 3.0 dilemma was just the last drop in the bucket, so to speak.


So, here's what I'm proposing: 

1. Zend_Translate to replace parts of the i18n class (and the _t() method).

3. Switch the default lang format in core to Gettext PO files.


There's numerous considerations with this suggestion -

I'm mainly concerned about getting this over the line quickly

even if it means some unpleasant compromises.

This decision has been hanging around way too long.


# Translator Platform

- Free project hosting and translator signup (unlimited translators)

- Web-based translation

- JavaScript translations

- Automated import/export onto github

- Manual approval of languages (might be achieved through selective export scripts  as well)

- Context strings (an estimated 5% of core entities have more context to clarify the string itself)

- Optional: Collaboration tools like voting or flagging a translation

- Optional: API to retrieve/update strings (maybe even collaborator stats)

- Optional: Import of existing translation stats so we can credit translators for past work (icing on the cake)


# Entity retrieval

- Existing i18nTextCollector should be easy to retrofit to any format we decide on. Its still an ugly mess of regexes though.

- Hard to replace completely, unless we do away with the concept of i18nEntityProvider and rely fully on static code parsing.


# Backend requirements

Zend_Translate fits, as we already use Zend_Locale, the underlying CLDR codebase and Zend_Cache,

so no new dependencies on top of that. Has many file backends, plus we can write our own one for legacy file support.

Will need to investigate caching abilities, we don't want to parse large amounts of YML or XML on every request.


# File format requirements

- Support for plural forms, so multiple translations for the same string based on quantity.

Thats not possible in the current i18n class, but its an essential localization technique that we missed.

- I think we can safely ditch the "priority" parameter currently present in _t(). Nobody uses it.


# File formats: Pro/Con


## Rails 2.2. YML

- Pro: Simple and readable file format. Arbitrary nesting. Simple context definitions through YML comments.

More likely to have useable and cutting edge tools for translators.

- Con: We'd need to build a custom Zend_Translate adapter (a similar adapter for *.ini is about 20 LOC though).

Tooling will be most likely around Ruby ecosystem, not PHP.


## Gettext

- Pro: Wide tooling support (e.g. Zend_Translate)

- Con: A bit arcane file format, will be hard to generate from current i18nTextCollector implementation.

Not sure about native Gettext parser support for our custom format with _t(id, string, priority, context).

Only reliably works with specialized parsers, although they're a'plenty in PHP.



- Pro: Wide tooling support (e.g. Zend_Translate), open standard

- Con: XML verbosity and uglyness. Will take uncompressed core lang files from 2.8MB currently to an estimated 10MB.


## PHP Arrays

- Pro: No caching required, close to the current format.

- Con: Inconsistent tooling support, no standard format. E.g. getlocalization supports it, but not with context or pluralization.


Links to i18n topics:


Links to alternative translation web tools:


OK, a lot of info :) Let me know what you think.




Ingo Schommer | Senior Developer


You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at