-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Translation in french #92
Comments
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!) |
I'll start by doing this. Shall I simply start by adding a Once this is done, we'll see how to help with the translation of the editor. Thanks! |
@bzg that is perfect! 🎉 |
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). |
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 |
@ruphy @bzg Here's a proof of concept using @ruphy I'm not sure I understood the remark about schema files, aren't strings in |
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. |
@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. |
@ruphy Thanks for the clarification, that's interesting! So something like:
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). |
@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? |
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 ideas I came up with are quite bad:
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. |
@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? |
Sure, let's do it. |
@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 |
This seems to be the correct link: publiccodeyml/publiccode.yml#75 |
Import @garronej's translation from codegouvfr@b02931a https://github.com/codegouvfr/publiccode-editor/blob/2a807b98de5e99207ca1f6a17c4a7d6c71deadad/src/app/i18n/translations.js Fix italia#229. Partially implement italia#92.
Import @garronej's translation from codegouvfr@b02931a https://github.com/codegouvfr/publiccode-editor/blob/2a807b98de5e99207ca1f6a17c4a7d6c71deadad/src/app/i18n/translations.js Fix #229. Partially implement #92.
@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 https://publiccode-editor-develop.vercel.app/?lang=fr I'm keeping this open because not all strings are translated yet (wink wink) ;) |
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.
|
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!
The text was updated successfully, but these errors were encountered: