Translation in french

[bzg]

Dear all, thanks for publiccode-editor!

I would like to promote the use of publiccode.yml files for public code in France.

I see you are discussing an italian translation - where should I start for working on a french translation?

Thanks for your answer!

[ruphy]

Hello @bzg ! This is wonderful news. As you can read in the task you linked we didn't get to implement the Italian translation for this interface yet, as the translation infrastructure still needs to be figured out, and with the schemas it's not an obvious technical solution. I wanted to pick this up in the next few months but you're more than welcome to start hacking on tihs!

If want to promote the use of the format in France, I would say that a necessary first step would be to translate the specification itself to French. However, if you still prefer to work on this localization task first, you will need to take a look at the schemas and understand how to load a localized version, whether that means compiling a different version to be deployed on a separate infrastructure, or we can work on it client side. Ideally I would fully automate this translation work (gettext and po files), to ensure it remains consistent between the languages and with the specification itself.

(btw, we're working to transition the governance of the project to OASIS, let me know if you'd like to know more about it and/or be involved!)

[bzg]

If want to promote the use of the format in France, I would say that a necessary first step would be to translate the specification itself to French.

I'll start by doing this. Shall I simply start by adding a fr/ directory in this repository? Or are there other repos to translate?

Once this is done, we'll see how to help with the translation of the editor. Thanks!

[ruphy]

@bzg that is perfect! 🎉

[libremente]

If want to promote the use of the format in France, I would say that a necessary first step would be to translate the specification itself to French.

I'll start by doing this. Shall I simply start by adding a fr/ directory in this repository? Or are there other repos to translate?

Once this is done, we'll see how to help with the translation of the editor. Thanks!

Hi @bzg, yes that would be great! Let me know if you need help on that (since such documentation is currently deployed on top of our Docs Italia).

[bfabio]

I'm more familiar with Vue and it's i18n plugin, what's the canonical solution with React?

The most popular project I found are https://github.com/i18next/react-i18next and https://github.com/formatjs/react-intl, and honestly the former makes more sense to me

[bfabio]

@ruphy @bzg Here's a proof of concept using react-i18next.

@ruphy I'm not sure I understood the remark about schema files, aren't strings in contents/fields/*.js the only source for user facing strings when it comes to fields? If not, I guess #103 changes that? I'm probably missing something, though.

[libremente]

@ruphy @bzg Here's a proof of concept using react-i18next.

@ruphy I'm not sure I understood the remark about schema files, aren't strings in contents/fields/*.js the only source for user facing strings when it comes to fields? If not, I guess #103 changes that? I'm probably missing something, though.

Hi @bfabio, #103 does not change anything regarding the schema, it's just about the way the validation happens.

For me +1 for @ruphy's idea to use .po files, IMHO it makes the whole process way faster.

[ruphy]

@bfabio what I care about is that we don't have to indipendently maintain n copies of different translations for keeping the standard and the editor updated. Gettext offers an elegant and well tested soluton to deal with the problem, and this definitely does not conflict with your idea. The technological issue to solve (and needs some additional research) is how to have an automated or semi-automated way to ensure the editor is consistent with the specification.

Regarding my comments about the infrastructure, I'll rephrase it very technically: the important thing is that files such as src/app/locales/it.js in your POC (thanks for that!) are not created by hand but generated automatically by an English "master copy" and a .po file which defines its translation.

[bfabio]

@ruphy Thanks for the clarification, that's interesting!

So something like:

1. xgettext creates / updates the .pot file
2. The translator creates the language .po file with msginit or updates the existing .po file with msgmerge
3. Something in the build script creates the data accessible from Javascript

keeping the standard and the editor updated

Do you mean having the same .pot file for both the standard and the editor? I don't know if we want that, I think the user facing messages should be a little bit different (See #102).

[ruphy]

@bfabio yes! And the translator can use one of the many UIs available for translation. There are gettext tools to recreate the javascript from a master file (see for example KDE's scripty or tools such as this)

Related to the comment about sharing the same .pot/.po file, I didn't really make my mind up yet. I would like to keep them somehow synced, but I can see cases where that wouldn't be possible. What do you think of keeping the standard as a default, with the possibility in the editor to override the strings which are not clear? This could allow the "format" specification to fix bugs in its wording, minimizing the chances of someone forgetting to backport the fix to the editor. Any thoughts?

[bfabio]

Related to the comment about sharing the same .pot/.po file, I didn't really make my mind up yet. I would like to keep them somehow synced, but I can see cases where that wouldn't be possible. What do you think of keeping the standard as a default, with the possibility in the editor to override the strings which are not clear? This could allow the "format" specification to fix bugs in its wording, minimizing the chances of someone forgetting to backport the fix to the editor. Any thoughts?

When we say "the standard", we are referring to https://github.com/italia/publiccode.yml/, right? So it would be a matter of using gettext on those .rst files (which are supported by gettext, I didn't know that).

A couple of things I'm not convinced of about sharing the translations:

• The message in publiccode-editor's source will not match what's displayed and that will confuse the developer. Let's say we have a message like "This foobar does this and that, refer to section 1 of the standard when the moon is full, [yadda yadda, snip super long text]" in the standard. That would need to be passed verbatim to the translation function, usually _(), in the editor, even if the resulting "translation" happens to be empty by means of that override mechanism. The user wouldn't see a strange message, but the developer would be scratching their head for sure.
  We would use translations to potentially change semantics of a message, and that makes me uncomfortable.
• The potential of being out of sync would still be there, albeit reduced and formalized. Whether you use git submodules or some other mechanism, the developer needs to sync the translations to the latest version manually.

The ideas I came up with are quite bad:

• Move the editor into the same repository of the standard, and use a single POT. The implication would be that, when a developer modifies the standard, they should check if the editor needs to be modified as well, like some sort of reference implementation. I don't think we want that.
• Have a monstruosity translation file in some made up format with both translations that generates the two .POT: Rube goldbergian + we are coupling the standard with the editor anyway

Ultimately I think the two translations, even if related, are distinct by nature in having two different audiences. Unfortunately I don't have a satisfying solution if translation sharing is in the picture.

[ruphy]

@bfabio thank you for the thorough analysis.

I gave some more thought to the issue and I agree with it. At this point we'll have to maintain two different sets of strings, just like we maintain two different repositories. Maybe we'll be able to copy over the translation over once, but for sure we will keep a clean separation. I don't expect the strings to change too frequently anyways.

Now, about the implementation. Do you want to help get it done? If so (which would be wonderful!), do you want to schedule some time to talk about it on a high bandwidth channel (slack/IRC/phone/...) and we can plan the work?

[bfabio]

Now, about the implementation. Do you want to help get it done? If so (which would be wonderful!), do you want to schedule some time to talk about it on a high bandwidth channel (slack/IRC/phone/...) and we can plan the work?

Sure, let's do it.

[ruphy]

@bfabio and I had an initial call to discuss how to implement the translation infrastructure. More details on https://github.com/italia/publiccode.yml/issues/75

[Smart-City-Muenster]

This seems to be the correct link: publiccodeyml/publiccode.yml#75
(I found some strings still in Italian and stumbled over this issue.)

[bfabio]

@bzg @garronej we imported your translation work into the wip devel branch, you can check out the preview here:

https://publiccode-editor-develop.vercel.app/

The new i18n system should detect the browser's language out of the box and serve the right one, or it can be forced with the lang param like this:

https://publiccode-editor-develop.vercel.app/?lang=fr
https://publiccode-editor-develop.vercel.app/?lang=it
https://publiccode-editor-develop.vercel.app/?lang=en

I'm keeping this open because not all strings are translated yet (wink wink) ;)

[bzg]

I'm keeping this open because not all strings are translated yet (wink wink) ;)

Well noted! I keep this in my (long) to-do list.