French i18n improvements

[r3n4ud]

This issue number may also refer to the older ticket #143, now #1610.

Rebased to master. Not even to the first quarter of the whole task…
To be continue…

[dnrce]

Is this using Tolk now? Ideally, any .yml files should be a direct export from Tolk with no subsequent hand modification.

[r3n4ud]

No. Handmade… I've not succeeded in using Tolk up to now. It should be smart enough to reprocess from the modified yml file, no?

[dnrce]

Unless the escapes were needed. I'm going to test before I merge.

Let's talk more about getting Tolk running. I think it will be helpful to you. I'll send an email to the address in your commit author line.

[dnrce]

I'm closing this for now until you get Tolk running. c97d2b2 should not include any escape or quoting changes. Any translations should be passed through Tolk even if the changes were made manually. This standardizes the formatting and makes the real changes more visible in a diff.

[lrbalt]

Tolk stores all keys in the database. There is a rake task to sync the yml-files to the database.

[r3n4ud]

Do you consider the initial strings standardized ?

Dan Rice notifications@github.com a écrit :

I'm closing this for now until you get Tolk running.
c97d2b2 should not include any escape
or quoting changes. Any translations should be passed through Tolk even
if the changes were made manually. This standardizes the formatting and
makes the real changes more visible in a diff.

---

Reply to this email directly or view it on GitHub:
#143 (comment)

Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.

[lrbalt]

en.yml was handcrafted. But Tolk generates the other yml from the strings in the database, so the preferred workflow is

• new string in en.yml
• use Tolk to translate to other locales
• Tolk genereates the .yml for each locale
• check into repo

If we manually change fr.yml, there is no big problem, we just need to import the changes into the database so that Tolk doesn't overwrite your contributions.

[dnrce]

@lrbalt Other translators will need to import the changes regardless of whether or not he uses Tolk, because only the yml files are checked into git, not any database data.

@nibua-r If by "initial strings" you mean the English strings then no, they are not as standardized as the others because Tolk doesn't create the YAML for English. If you mean the version before your manual edits, then yes, that was the standardized version output by Tolk. Cleaning up the quotes, escapes, and line endings in the YAML is a great effort, but unfortunately it ends up being for nought because the next use of Tolk will wipe out those changes. In fact it is counterproductive because it obscures the substantive changes, both in this changeset and in the next subsequent changeset that uses Tolk.

In this case your proposed commit c97d2b2 changes 198 lines. After running the updated version through Tolk it becomes a 244-line change due to the whitespace changes in your previous commit. After running both the before and after versions through Tolk, it turns out the real changes in this commit are actually to 132 lines. This is a great contribution! But the other stuff ends up being noise.

I would just pass this through Tolk myself and commit it, but I would like the changelog credit to go where it's due.

[r3n4ud]

I'll check that out tomorrow (today was a tough day).

Dan Rice notifications@github.com a écrit :

@lrbalt Other translators will need to import the changes regardless of
whether or not he uses Tolk, because only the yml files are checked
into git, not any database data.

@nibua-r If by "initial strings" you mean the English strings then no,
they are not as standardized as the others because Tolk doesn't create
the YAML for English. If you mean the version before your manual edits,
then yes, that was the standardized version output by Tolk. Cleaning up
the quotes, escapes, and line endings in the YAML is a great effort,
but unfortunately it ends up being for nought because the next use of
Tolk will wipe out those changes. In fact it is counterproductive
because it obscures the substantive changes, both in this changeset and
in the next subsequent changeset that uses Tolk.

In this case your proposed commit
c97d2b2 changes 198 lines. After
running the updated version through Tolk it becomes a 244-line change
due to the whitespace changes in your previous commit. After running
both the before and after versions through Tolk, it turns out the
real changes in this commit are actually to 132 lines. This is a great
contribution! But the other stuff ends up being noise.

I would just pass this through Tolk myself and commit it, but I would
like the changelog credit to go where it's due.

---

Reply to this email directly or view it on GitHub:
#143 (comment)

Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.

[r3n4ud]

OK, I got Tolk up and running. I'll rework my updates to fit with the required workflow but I have a question: how do you manage special UTF-8 whitespaces like nbsp or narrow nbsp?

Just my feeling, but it seems to me that distributing locale into several files, a good text editor and rigorous sorting rules can yield to a better result. Yes, the drawback of this approach is that this can be overwhelming for non-programmers / translators…

[dnrce]

I haven't worked much with the translations but I believe any UTF-8 character can be entered directly into Tolk. In many cases the Tracks application will escape strings to their HTML entities during rendering. However, there may be cases where you discover encoding issues. If so, they are probably bugs in Tracks that need to be solved rather than worked around in the localizations.

At the moment we have settled on Tolk. A key feature it provides is showing strings that are untranslated into secondary locales. If you have a better tool to suggest, please do. But we don't want to be writing and maintaining our own. "Not reinventing the wheel" is core to the Rails philosophy.

[r3n4ud]

Why Tolk add those trailing whitespaces? Any idea?

[dnrce]

No, but you got me curious. Tolk uses ya2yaml under the hood, which is designed for maximally compliant UTF-8 output. Looking in the ya2yaml source shows that ya2yaml simply doesn't make a distinction between one-line key-value pairs and nested values. Since YAML requires a space after the colon in a one-liner, ya2yaml never outputs ':', always ': '. The choice seems rather deliberate (--- is always output with a space, as well) but the git history doesn't go back far enough so I'm not sure if there is a compatibility motivation for this, or if it was just the easier way to code it.

[r3n4ud]

KISS result is my guess…