Symphony.

@Nils It works now!

You are using a local Symphony setup on a Mac, right?

Right, I’m not using MAMP or anything else. I did some changes on apache’s settings. /etc/apache2/. That’s what you wanna know?

Right, I’m not using MAMP or anything else. I did some changes on apache’s settings. /etc/apache2/. That’s what you wanna know?

That’s just fine – I thought of a server related problem before finding the regex that didn’t match languages with dashes.

By the way: Some of the core extension make use of hardcoded language strings (Maintenance Mode, Export Ensemble, JIT Image Manipulation …). I send some pull request for these extensions with added calls to Symphony’s translation function.

Hi Nils, there seems to be an issue with some Translations, e.g. whe I create an Section called ‘Sections’ you manager translates this to ‘Bereiche’. Is there any workaround?

Nils this is brilliant! Good work.

martinproject posted an 83%(!) complete Spanish version. I haven’t seen martinproject around since so not sure if he’s completing it.

Hi Nils, there seems to be an issue with some Translations, e.g. whe I create an Section called ‘Sections’ you manager translates this to ‘Bereiche’. Is there any workaround?

That should not happen. “Bereiche” should only be used as the German translation for “sections” in the menu. Is the name translated throughout the system?

… whe[n] I create a Section called ‘Sections’ you[r] manager translates this to ‘Bereiche’.

And to clarify one thing:

The Localisation Manager itself does not enable back-end localisation. Symphony is capable of handling multiple languages since a year – it’s a core feature. Localisation Manager is only bundling language files and helps to find and export language strings that need to be translated.

So if there are translated strings in the interface that shouldn’t be translated, there is bug in the core or in an extension you depend on.

Is there a simple way to see how “complete” the translation is? Probably not the most necessary feature ever, but would be fun.

Marcin’s Translation Manager had this feature, but I think it’s not that helpful: The completeness depends on the number of extensions used and on their version numbers.

What do you think?

Hi Nils, there seems to be an issue with some Translations, e.g. whe I create an Section called ‘Sections’ you manager translates this to ‘Bereiche’.

I just pushed a small change to GitHub that should help you with the translation of sections named “sections”, at least in the main navigation: http://github.com/nilshoerrmann/localisationmanager/commit/00c4f1936289d4424b9ed6d8536855d2bfe505d8

Thanks Nils, it works just fine now :) Sorry for the bad spelling in my first post.

@Nils: My proposal is to agree a list of supported extensions and stick to it, in order to guarantee that each language pack will include the same strings.

Regarding the versioning process, I think version numbers may be employed to describe how complete and up-to-date is a given translation compared to others. Every time the Symphony core or extensions from the above-mentioned list are updated with new strings, language packs become out-of-date and need to realign with the English localisation which, in the meantime, gets a higher version number. Would it make sense?

Plus, I’d suggest to choose which terms should be kept in their English form against those that need to be translated. As far as the Italian language pack is concerned, we decided to leave untouched words like template and ensemble: while the former is very popular among developers, the latter belongs to the same “namespace” as symphony and has been adopted by users of this community since the beginning, so breaking with the past wouldn’t be a smart move.

Nils, should we open a new thread to discuss these issues?

I’ll be offline for the next days, so just some short notes:

Regarding the versioning process, I think version numbers may be employed to describe how complete and up-to-date is a given translation compared to others.

This would mean, that we’d have a general version number for Localisation Manager and a specific version number for each translation file, right? Can you give us an example of a possible structure of this number?

Plus, I’d suggest to choose which terms should be kept in their English form against those that need to be translated.

This has been a long discussion last year, too. There is one problem: If you start discussing which strings should not be translated you’ll find arguments why each area of the system – one after the other – should not be translated. That’s why I think it should be up to the translators how they translate the system. It depends on the context of the respective language, if a translation suits well or if a string should be left in English. If you think “template” should not be translated, why shouldn’t we keep “data source”, too? What about “utility”? I think you know what I mean.

Most important is consistency within one language file.
The developers’ language will still be English and users with translated interfaces will know how to handle bilingual Symphony names.

Nils, should we open a new thread to discuss these issues?

Maybe that’s a good idea.

Post scriptum:

My proposal is to agree a list of supported extensions and stick to it, in order to guarantee that each language pack will include the same strings.

While this might work in the beginning, how should we then handle abandoned translations files, if new extensions should be added?

Question 1: How important is it to have the progress of translation synchronized?
Question 2: Who decides which extensions to translate and which not?

I think we should not be too restrictive in order to get translations running and to keep the process alive. But please feel free to discuss these issues!

Who decides which extensions to translate and which not?

Just two quick thoughts: first, it probably makes sense for language files in the Localisation Manager to cover the core extensions; and second, that the only real sustainable way to handle non-core extensions is for the extensions themselves to bundle their own translations. Does that make any sense?

@czheng It makes sense. Also it’s not a good idea to keep all extension’s translation on a single file.

Does that make any sense?

Yes, but it didn’t work until now :)

It could be done quite simple: just add a lang folder to each extension with localisation files in it.

Also it’s not a good idea to keep all extension’s translation on a single file.

That’s true. But as mentioned a few lines above: It didn’t work until now. It’s even hard to push language files to core extensions. (I’ve tried it a few times …) Furthermore it is a hard job to keep track of localisation files split over more than hundred extensions …

This is why I currently bundle all strings in one file. It’s the only way to add localisation strings if the creator of an extension does not integrate your language file.

Yes, but it didn’t work until now :)

@Nils: It’s indeed hard to follow the localisation efforts and ideas. If the concept is considered stable, maybe you could open a new forum thread containing instructions and example files for extension developers?

As I promised, Brazilian Portuguese translation released.

I am working on a Dutch translation and I find that I’m not able to translate everything. It would be nice to be able to translate Maintenance Mode, Export Ensemble and JIT Image Manipulation.

Also, in the line '%s %s at %s. <a href="%s">Create another?</a> <a href="%s">View all %s</a>' the second %s is an action which I am not able to translate. I am able to switch around the word order making the translation less bad with %1$s %3$s %2$s etc, but updated and created ares simply not Dutch. This translation appears when creating/updating page. Same goes for '%s %s at %s. <a href="%s">View all %s</a>' which is called when updating page xslt.

I will go through the System to discover as much of these snags and post the translation on Github later.