Contributor

• Switching to fr locale code, as we never use fr-FR in Mozilla projects and the translation is neutral enough to target all french-speaking countries.
• Fixing typos and broken link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

Contributor

👍

Contributor

Switching to fr locale code,

Hm, I'm not sure if we should do this on a per-locale basis or not. Right now, it's to always use the extended one.

This PR still has conflicts as well.

Contributor Author

Hm, I'm not sure if we should do this on a per-locale basis or not. Right now, it's to always use the extended one.

Using fr-FR would make only sense if we wanted to maintain translations for French spoken in France, then add different translations for French spoken in Belgium, Canada, etc. Which we won’t do because this is a neutral translation and would be a pain to maintain.
Using “fr” is consistent with what we’re doing on every other Mozilla website and product. It’s also totally fine to mix extended locale codes with non-extended ones. As a reference, here are the locale codes used on Mozilla.org https://github.com/mozilla/bedrock/blob/master/bedrock/settings/base.py#L120-L133

This PR still has conflicts as well.

There was none an hour ago ;) Thanks, now fixed

Contributor

I understand, but Mozilla policy doesn't just make it Rust policy.

On Oct 6, 2016, 14:00 -0400, Théo Chevalier notifications@github.com, wrote:

Hm, I'm not sure if we should do this on a per-locale basis or not. Right now, it's to always use the extended one.

Using fr-FR would make only sense if we wanted to maintain translations for French spoken in France, then add different translations for French spoken in Belgium, Canada, etc. Which we won’t do because this is a neutral translation and would be a pain to maintain.
Using “fr” is consistent with what we’re doing on every other Mozilla website and product. It’s also totally fine to mix extended locale codes with non-extended ones. As a reference, here are the locale codes used on Mozilla.org https://github.com/mozilla/bedrock/blob/master/bedrock/settings/base.py#L120-L133

This PR still has conflicts as well.
There was none an hour ago ;) Thanks, now fixed

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (#561 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AABsihM22pNbAhGezJbhqfxZD--te6VRks5qxTckgaJpZM4KLzbk).

Contributor Author

I understand, but Mozilla policy doesn't just make it Rust policy.

Sure, of course. Just trying to understand why you would prefer fr-FR over fr, beyond consistency with existing locale codes.

Contributor Author

Would appreciate if someone could review this one as I don’t think I will have much time to rebase it a fourth time.
Thanks!

Contributor

So sorry about that. :(

I still don't know what to do about fr vs fr-FR.

Otherwise, looks good to me. @brson what do you think?

Contributor

sgtm. The language codes can be sorted out later.

Contributor

On the language codes: I think, if nothing else, that keeping the extended codes keeps the URLs as unsurprising as possible, which is a small bonus. Additionally, it leaves the door open for some future additional translation, if some intrepid person in fact wanted to provide a translation in Luxembourg French, Canadian French, etc. The reasons for using the shortened code seem comparatively thin. Sure, it saves a few characters and is consistent with Mozilla policy, but Rust is (as the FAQ points out) not controlled by Mozilla, so I don't think that consistency with Mozilla policy is of any particular relevance to the decision.