Skip to content
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

Explicitely warn using non-practical language codes #3559

Closed
PanderMusubi opened this issue Mar 4, 2020 · 3 comments
Closed

Explicitely warn using non-practical language codes #3559

PanderMusubi opened this issue Mar 4, 2020 · 3 comments
Assignees
Labels
enhancement Adding or requesting a new feature.
Milestone

Comments

@PanderMusubi
Copy link

PanderMusubi commented Mar 4, 2020

Is your feature request related to a problem? Please describe.

We have discussed this shortly at FOSDEM 2020. The same Dutch language is used in the Netherlands, Belgium and Suriname. Of course, there are local variations, dialects and customs, but in general for software, only one Dutch translation is made. The official rules on spelling, grammar, etc. are identical.

However, the following language codes and locales exist:

  1. nl Dutch in general
  2. nl_AN Dutch in Netherlands Antilles (was a constituent country with the Kingdom of the Netherlands)
  3. nl_AW Dutch in Aruba (is a constituent country with the Kingdom of the Netherlands)
  4. nl_BE Dutch in the Kingdom of Belgium
  5. nl_NL Dutch in the Kingdom of the Netherlands
  6. nl_SR Dutch in the Republic of Suriname

Many many times, developers and translators are not aware that only one Dutch translation needs to be made and/or think that they should choose the language code as specific as possible. Usually this is done with the best of intentions.

In the past en present, this resulted in often two or three translations all trying to do the same translation. Consolidating is sometimes difficult as personal style or choice of words can differ of the different translations, and not that the official language differs. In short, it creates unintentionally a lot of extra work in translating and managing a translation and subsequent software release where the translation is used.

Describe the solution you'd like

Proper internationalized and localized software will switch to e.g. a language code nl if a more specific version such as nl_NL or nl_BE is not available but requested by the operating system.

New and existing projects on Weblate should warn translation maintainers when a language code of nl_* is used and motivate them to refactor and consolidate translations to nl only.

A similar case could be made for en_NZ and en_IE representing English in New Zealand and Ireland with respect to en_GB English in Great Britain. But of the 20 country codes related to English, this is more tricky to define with American, etc.

Of course, the translation maintainer should be able to ignore this warning, but should also be able to reread it at a later point in time somewhere in the settings of a project.

Describe alternatives you've considered

Simply not allowing translations to nl_*, only nl, but that is too forceful and unwanted because some exceptions on for example texts on national law can be found, but these are an extremely tiny amount of the translations. Usually exceptions are found in software content and not in the translation of the software buttons, labels, etc.

Additional context

Implementation could be via these configurations:

  • nl:nl_* (when regex is supported) otherwise nl:nl_NL nl_BE nl_SR nl_AW nl_AN
  • en_GB:en_NZ en_IE

Also language code formats such as ca_ES@valencia and ca_ES-valencia should be supported.

@nijel nijel added the enhancement Adding or requesting a new feature. label Mar 4, 2020
@nijel nijel added this to the 4.4 milestone Sep 15, 2020
@nijel
Copy link
Member

nijel commented Sep 15, 2020

I think this should be used to limit list of languages offered to users while adding new translation to reduce amount of garbage added by contributors (this includes adding of en_devel and similar testing locales). On the other side, I don't think Weblate should warn in case such files are already present as there might be good reasons for that.

@nijel
Copy link
Member

nijel commented Oct 23, 2020

Just received another feedback on this topic:

What would be amazing, would be custom language lists only shows to users when adding new languages. That way we could have the default language list with all available Weblate languages. And a custom list configured in the Django admin interface only visible for users when adding new languages to a component. In this custom list we could add only the wanted languages for Kodi.

@github-actions
Copy link

Thank you for your report, the issue you have reported has just been fixed.

  • In case you see a problem with the fix, please comment on this issue.
  • In case you see a similar problem, please open a separate issue.
  • If you are happy with the outcome, don’t hesitate to support Weblate by making a donation.

nijel added a commit that referenced this issue Nov 27, 2020
It should accept custom defined languages as well, not only the built in ones.

Issue #3559
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Adding or requesting a new feature.
Projects
None yet
Development

No branches or pull requests

2 participants