Symphony.

1. What's with the funny acronyms?

There is a big difference between internationalisation (i18n) and localisation (L10n), meaning they are not interchangeable, so it is important to know what each term signifies and implies.

Internationalisation (i18n): Translation (language)

Localisation (L10n): Adaptation of language, content and design to reflect local cultural sensitivity. E.G. supporting region specific date formats, currencies, paper sizes etc.

Symphony 2 focuses primarily on i18n, or sometimes referred to as localisation enablement. i18n is often described as a pre-cursor to L10n, such that it facilitates future attempts to localise an application. Symphony 2 offers a path to localisation, but we are primarily concentrating on the 'pre-cursor' phase, internationalisation.

2. Reasons why Symphony 1.7 had neither

There were a number of reason why Symphony 1.7 failed to contain any i18n related features. Mostly it was due to a combination of inexperience and an inflexible code base. Remember that we started Symphony back in 2004, and the code base, framework & coding paradigms hadn't really changed a great deal since then.

There were other concerns as well. For instance, how do we offer i18n to Symphonians, and offer quality support when we cannot speak the language. Also, do we have enough community support to maintain the translations. Symphony has been evolving so rapidly that it was difficult to commit to such an undertaking when the core aspects were not even fully realised. Shortly after 1.7 launched, the idea of Symphony 2 started to creep in, pushing the arrival of any form of i18n back even further.

3. Looking forward

So, now the big news. Symphony 2 will fully support i18n at launch (beta period will not have full translation table support right away). Symphony 2 has a flexible system for supporting text string dictionaries and custom transliteration tables. There is a new API for developers, allowing simple integration of new languages.

4. How to contribute

Symphony 2 brings with it a brand new API, part of which includes i18n support. Every text string in Symphony is abstracted, and easily overloaded, allowing for complete interface translations, and accurate URL transliterations.

If you are interested in creating your own translation files, than take a look at the article covering what you can look forward to in terms of Symphony's new API structure. We also encourage collaborative efforts to help improve accuracy and completeness. Installing new language packs will be as easy as installing extensions. Drop the folder into your /extentions, and change your language preference via System > Settings

I'd like to help with the German translation.

Ist noch jemand mit von der Partie?

Count me in for Dutch translation guys.

@Skubidu: We talked about this a long time ago. I will be glad to help.

Hey newnomad, count me in for the Dutch translation too.

Well Carsten I can do Flemish, bet you can't ;-)

I bet Flemish would be really popular... Whoops there goes my money :P

I could help/do (for) the french translation.

Count me in for the Italian translation, it'll be a pleasure

Count me in for the Italian translation, it'll be a pleasure

I'll be glad to help with it as well. ;)

I can also help for the german part Skubidu

I can help with English :-)

Symphony 2 brings with it a brand new API, part of which includes i18n support. Every text string in Symphony is abstracted, and easily overloaded, allowing for complete interface translations, and accurate URL transliterations.

Alistair, is there any time schedule when we get more details on this new API. I'd like to start playing with translations :)

Very soon I hope. Along with delegates, this is at the top of my list. Really all that needs to happen is I find all the strings in the system and add them into the symphony/lib/lang/lang.en.php file. Then, where that string appears, wrap it with __() to trigger the dictionary translation before rendering.

We have started working on the German version, already thinking about the most important navigational items and other terms in the Backend GUI. We would like to stick as close as possible to the original English version.

One question might be interesting for other languages as well:

Is the term Blueprint intended to remind the user of old-fashioned blue-line prints (which is the first possible meaning in German) or carbon-copies (the second meaning in German)? Or is it used as a synonym for plans, layouts or schemes?

@symphony-team: Please simply tell us your intention. We will try and find the closest translation.

We would like to stick as close as possible to the original English version.

Unfortunately it might not be a good idea to start on this yet, since the English version is certain to change before the final release. There is one major UI addition we are yet to add, and a lot of the language needs to be revised for clarity. I think we should try to get a "language stable" version out in the next few weeks, which will give you a better place to start.

"Blueprints" is just a term we used to denote logic/structural data relating to the front-end, it really doesn't matter what the term is so long as this is understood. I'd prefer to see something that makes most sense to German users, not necessarily something that's faithful to the original, so feel free to take liberties with all translations if you think there's a better term/phrasing that will make more sense. :)

Thank you, Scott!

I'd prefer to see something that makes most sense to German users, not necessarily something that's faithful to the original, so feel free to take liberties with all translations if you think there's a better term/phrasing that will make more sense.

I would advise against changing names of the admin areas for other languages. This is a documentation nightmare and could create some serious confusion because documentation and current community support is English-based.

Good point, I hadn't considered that. Listen to the man who has experience writing documentation. :)

That would make it the "old-fashioned blue-line print" connotation. My point still applies to less important/visible language strings throughout the interface.

I would advise against changing names of the admin areas for other languages.

In this case we should not start with any translation. A half translated interface does not work.

Experiment of mind: Think of Hindi or Swahili as Symphony's native language. You as an English speaker would like to use the system because it's great. Neither your Hindi nor your Swahili it that good but there is a translation (wohoo!). You install everything just to find out that they did not translate the most important part: The site navigation?! Come on ...

If we start with a only partly translated interface, where should we stop? We should not translate blueprints but should we translate pages, components, sections? No? Okay ... let's see. A section has got fields. That's a very important feature, we should not translate that ... etc ... etc ... etc ...

Sorry for my sarcasm. I know that it's going to be difficult to deal with documentation and internationalisation but that's in the nature of things.