Search

There have been a lot of discussions about the Whats, Whys, and Hows of translating Symphony, so I decided to create a new thread in order to collect here every thought about it.

Note: I’m not that good at writing summaries, plus English is not my first language. If something is unclear, please tell me and I’ll try to explain myself better!

To translate or not to translate

As I already said a while ago, I strongly believe that we must choose which terms have to be translated against those that are already functional in their current English form.

Anyway, Nils correctly pointed out that:

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.

[…]

There are still some problems with untranslatable strings (mainly in the core extensions) and there is no agreement on how to handle “core terminology” (sections, field, data source, event). Which is quite important now that we have a documentation. Personally I think we should translate all parts of the system (core terminology, too)

Sorry, I’ve been very busy in the past few weeks so I had not time to reply. I see your point, but I don’t completely agree.

Ideally, each term belongs to one of the following categories:

  • Terms whose meaning is inherited from other contexts and/or is obvious only in some cultures (e.g. “Blueprints”, “Ensemble”)
  • Terms whose meaning is obvious within the current context, whatever the language is (e.g. “template”, “query”, “database”);

Frankly, I don’t know how it works in English but, as far as Italian is concerned, there’s no suitable translation for “Blueprint” - apart from “cianografia”, which looks quite strange and ambiguous as navigation item. On the other hand, the same effect can be achieved translating “queries” or “template” from English to Italian (note that links point to the Italian version of Wikipedia).

Here’s my point: if a term belongs to the first category, it needs to be translated unless its use is widespread amongst the community (e.g. “Ensemble”); if a term belongs to the second, it doesn’t need any replacement.

Versioning language packs

I said:

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?

I’ve been asked to give an example of how to do that. Well, each version of Symphony is made of three digits (e.g. “2.0.6”), right? Fine, packages on ArchLinux are maintained by using version numbers and revisions. Each package represents an app. If a broken package gets a fix and the version number of the app’s latest release hasn’t changed in the meantime, your only way to notify the upgrade is by increasing the revision number.

As for Symphony language packs, I think we can recycle the idea and adopt the following schema: current_version_number-current_revision. If the version number of the translation is the same as Symphony’s, then the translation is up-to-date.

One language file to rule all the extensions

My proposal was:

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

However, it wasn’t a really good idea. In fact, as Nils said:

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?

czheng made a good point here:

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?

Regarding the first question, I guess it could be useful to know how up-to-date a language pack is. The only way I’ve found so far to do that is by making the versioning process conform to a standard. I’m sure there may be other alternatives, anyway.

Translating documentation

The issue has been raised by Nils:

[…] we would […] need an area in the documentation with a list of original and translated core terms (it would be best of course to have a multilingual documentation – but that seems to be too much for the moment).

Nils, these are good ideas. I bet there are many volunteers yearning to contribute somehow, for example by working on a translated version of the documentation.

Thanks for your summary.

Are there any official comments by the team?

Ideally, each term belongs to one of the following categories:

  • Terms whose meaning is inherited from other contexts and/or is obvious only in some cultures (e.g. “Blueprints”, “Ensemble”)

  • Terms whose meaning is obvious within the current context, whatever the language is (e.g. “template”, “query”, “database”);

The problem with the categories you mention is that it depends on the language that the term is translated to. I think that the meaning of most words is not obvious within the context of Symphony, that’s one of the main reasons for translating the system. I don’t think it is possible to categorize English words in either category beforehand. Already in the examples you give, there is a Dutch translation for “blueprints” and also for “templates” which is not that obvious at all for most inexperienced Dutch users. It was hard for me to come up with an adequate translation of “entry”, and I translated it with “item” in the end.

What helped me out if there wasn’t a one-to-one translation for an English word was looking up some translations in the German language file and seeing if I could translate that. This practice also creates consistency among the different translation.

Are there any official comments by the team?

There will be, soon. Sorry for the delay.

@carsten:

I don’t think it is possible to categorize English words in either category beforehand. Already in the examples you give, there is a Dutch translation for “blueprints” and also for “templates” which is not that obvious at all for most inexperienced Dutch users.

In this case, I’d suggest to use a synonym for “blueprints” and leave “templates” untranslated. As I said, there are words that don’t need replacements (like “templates”), while those that need (like “blueprints”) can be translated using their exact equivalent or a word which better expresses the concept.

The problem with the categories you mention is that it depends on the language that the term is translated to.

That’s true. Mine is just an ideal (and likely to be rough) categorization for terms involved in the process of translation, anyway. In my opinion, the best we can come up with so far is treating the weak cases and basing the discussion on them: should we translate “Ensemble”? What about “Blueprints”? “template”? “query”? etc. According to the answers to these questions (and others), all the rest is up to the translator.

I’d like to propose of few steps for a working language managing and distribution system:

Language selection

Language selection should become part of the Symphony core. As soon as the system detects languages other than English it should show

  • a drop down in the system preferences and
  • a drop down in the authors profiles.

Therefore a new column should be added to the author table in the database containing the personal language preference. This column may either contain the value system for the standard language selection or the name of an individual selected language, e. g. dutch.

Personal language settings should override system wide settings. This is exactly how the Localisation Manager currently works.

Distribution of core translations

Each language should be published as a single extension containing only the core translation strings. These extension only need to contain a lang folder with the language file and an extension.driver.php with the about array.

All available translations should be linked in the Symphony readme file.

Distribution of extension translations

Translations for extensions should be added directly to he lang folder of each extension. Strings that are available in the core should not be added these files again.

Translation management

For helping translators to create all needed files Marcin’s Translation Manager should be updated to work with Symphony 2.0.7. It offers separate file creation for core and extension translations and shows the current state of the translation (as a percentage of translated strings).

  • Question for the team: Would it be safe to start working on a core implementation of translation management (language selection and strftime() usage)?
  • Question for German Symphony users: The German translation has never been proof-read and I’m sure there are a lot of typos in it. Is there someone with the time to improve the translation file?

Is there someone with the time to improve the translation file?

Yes, I start today. In the next fews days i will send a pull request.

Greetings

Great, thanks! Please use http://github.com/nilshoerrmann/symphony_german for pull requests.

Please use http://github.com/nilshoerrmann/symphony_german for pull requests.

Okay! I create a fork.

I’d like to propose of few steps for a working language managing and distribution system […]

I completely agree with these proposals and I would like to add a few more notes:

Installation procedure

It seems reasonable to me to make translatable the entire installation procedure. Users could in fact select the desired language as the first step. Even if it’s not an issue that can be addressed soon, it’s definitely something to think of in the future.

Event description

I have noticed that the description of each event is statically stored inside the documentation() function of the associated event* class. When a new event is created/edited, the content of that function is generated by calling the __formAction() method of contentBlueprintsEvents. The output produced is a raw HTML fragment that is not sensitive to language switches.

This leads to inconsistencies as far as localisation is concerned. At time of installation, the default language is English and Symphony creates the events in the workspace/ directory producing English documentation for them. If I switch to another language, the documentation remains in English and I have no chance to change it but re-saving every event or editing each event.*.php file manually. This is true for every scenario which deals with an event creation and subsequently a language switch.

Given that the documentation follow some kind of schema (Success and Failure XML Examples + Example Front-end Form Markup + Customized documentation), wouldn’t it be easier to dinamically build the documentation only when the user is in the event editor? I think there are no reasons for relying upon a documentation() function which returns static content, but since I’m not a programmer I might be wrong.

Confirm dialogs and JavaScript strings

The current admin.js file handles strings in such a way that makes translation a bit complicated. Let me explain better with an example:

CONFIRM_SINGLE:   "Are you sure you want to {$action} {$name}?",

The above string is concerned with confirm dialogs used throughout the system to inform the user of a possible dangerous action (e.g. Delete) that can’t be undone. Fair enough. The problem is that the {$action} placeholder refers to the imperative form of the action itself, which is good for languages that don’t deeply distinguish imperative from infinitive (like English). Unfortunately, Italian doesn’t belong to that category and requires verbs in their infinitive form to end with a special termination (i.e. -are, -ere, -ire). This means that the mechanism used to generate grammarly correct sentences is not good enough for the Italian language (and many others).

My proposal is to create a string for each different action, by cutting away the {$action} placeholder and keeping intact the rest.

Hoping to have made my point :)

It seems reasonable to me to make translatable the entire installation procedure. Users could in fact select the desired language as the first step. Even if it’s not an issue that can be addressed soon, it’s definitely something to think of in the future.

I think the Symphony installer checks the language preferences of the browser to choose the best suited language pack. As the core does not contain any language files besides English, the installer will always be in English. This could only be changed by bundling the core language in the main ZIP file or by evaluating the extension folder for other languages. Shouldn’t be to hard to fix.

Concerning the JavaScript language strings: Maybe this is the right time to choose an approach that merges the JavaScript and PHP language files in one place.

Another option for the installation would be to separate the needed strings from the core translations and add the installation strings for all languages to the core. It would be possible to add a link to the needed core language file repository during the process as well.

This could only be changed by bundling the core language in the main ZIP file or by evaluating the extension folder for other languages. Shouldn’t be to hard to fix.

I forgot to mention one more thing related to translating extensions.

As Nils said some posts ago,

Translations for extensions should be added directly to the lang folder of each extension.

By the way, I think that maintaining both the extension and its localisations in a single bundle is almost impossible, because an update of a certain language file would force an update to the entire extension package as well.

A possible way to solve the problem could be to adapt this very website to the multilingual nature of extensions:

  • by providing a friendly interface for developers to translate strings of a given extension;
  • by implementing a modal window which, at time of download, asks the user for the languages he/she wants to include in the ZIP archive (this could be done for Symphony as well).

This way, translations could have a place to live on their own without affecting the extension they are associated with.

Are there more realistic solutions?

By the way, I think that maintaining both the extension and its localisations in a single bundle is almost impossible, because an update of a certain language file would force an update to the entire extension package as well.

Until we have something similar to the MooTools package builder for translations, this is just the way things should work in my opinion. Extension localisation files are rather short as they reuse many terms from the core. If version 1.3.0 of an extension gets an language update it should be releases as 1.3.0.1.

Has anyone considered an implementation of google toolkit - more for content- or webbased hosted po editor pootle? Ofcourse there are the offline solutions too.

There have been talks about using XLIFF files but this requires the change of some Symphony core concepts.

So this seems to be the second step to me.

Yeah it seems to me that if the team would install online editor tools, it would be much easier to get translations from community members, even non-programmers. Just like google translation toolkit its social translation; anyone can do it. Why not skip step 1 alltogether? ;-)

Why not skip step 1 alltogether?

Because step 1 is about implementing a language selection system into the core. I doubt step 2 will work without step 1 :P

Until we have something similar to the MooTools package builder for translations […]

(Yes, that’s exactly what I had in mind)

Has anyone considered an implementation of google toolkit - more for content- or webbased hosted po editor pootle? Ofcourse there are the offline solutions too.

Just for the sake of mentioning it, there’s also Launchpad (even if I haven’t ever used it).

If version 1.3.0 of an extension gets an language update it should be releases as 1.3.0.1.

Well… it seems a pretty awkward process, but perhaps we should stick to it anyway -for now.

In my opinion, what is of crucial importance to us is to have a package builder and a mechanism which associates localisations to extensions (Select Box Link? :) ). This way if someone releases an extension, we can translate it and publish a working localisation in a complete independent way. We can still wait for the whole “webbased editor with a friendly interface” thing, though.

step 1 is about implementing a language selection system into the core.

Is it possible to have such a system working by the time Symphony 2.1 is released? I understand that the team is already busy with plethora of more relevant concerns about the state of Symphony 2.0.7 and features for future releases, but I think that a working localisation system is becoming even more necessary day by day.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details