Translation of the distribution

Hum, sorry,

Bart can you upgrade langfed with the latest changes made on 7.x-1.x
After this, can you assign the ticket to Bald.

When is done, Bald will import the files into langfed.
Thx.

About #5

Every pages that use the CMS theme use only the English.
It's normal that the given example (https://langfed.rovin.be/nl/node/add/ofed-address) uses english language too, because the "add/node" pages are considered like admin pages (on OpenFed). A tips to know if you are on the CMS theme is to check the page logo. On the CMS theme the logo is different than the Nerra theme.

If you want to remove this behavior you can edit the "openfed cms theme/template.php" and remove from the line 7 to the line 19.

About #6

In the source code, each string that needs to be translated uses the Drupal t() function.
When we ask to extract the translations (for a defined scope), the system read the code to get each string in the t() function.
If a string doesn't use the function t() in the source code for a defined scope, it will not extracted.

The term "read more" is not include in the scope because its scope is the DS module.
You need to translate by hand at each time.

The term "published date" don't use the t() because it's a custom DS label that override the field label.
May be for this case we can make something.

About #7

l10n_update can be use to keep translations (not yet translated, of course) up to date.
This module is a nice to have... but it has nothing to do in this case.

Other solution:

Another solution is to translate the web site using the "translate interface" (https://langfed.rovin.be/nl/admin/config/regional/translate/translate). You can translate the terms what you want with this form.

When the translation is done, we will export (! not extract) all strings used in the website.
This file will contain all Drupal strings regardless of a defined scope. It's a big file (one for each languages).
The problem with this files is the initial importation of each of them during the install process.

The Drupal install process is not built to manage several translation file at the same time.
In the actual state of the code, it's not possible to put these files into the translations folder of the profile.

In the actual state of the code, we are not able to put this files into the "translations" folder of the profile as this is recommanded by drupal.
If we place the files, Drupal will propose more languages in the install step: "choose language". In this step, it's only one language that can be chosen (radio buttons), so only one file will be imported, because Drupal consider the website to be monolingual...

To set the languages correctly, we need to merge the step "choose language" and the step "set up regional". Even if we can do that, it's not sure that we will have the technical capacity to import several files with a batch script because each of them have a big size.

Conclusions:
Conclusion about #5 and #6:

If you don't like the other solution, you must accept that a lot of field needs to be translated by hand after the install process (and for each website).

Conclusion about #7:
This module is a nice to have... but interesting.
This module is interesting for the future but his analysis can be described into another ticket, beacause it has nothing to do in this case.

Conclusion about the other solution:

If you are interested by this alternative it's mandatory to merge two steps of the install process otherwise, we can't stock the languages file into the profile without having many confusion during the install. Even we can't use a batch script to import during install, it is still possible to add the language files by hand after an installation.

My part is done for the moment.
The translation process has begun.
Bart propose to remove the numbers in each translations files and keeping only what is needed.
I assign the ticket to him.