Support fallback to the "generic" language variant

[jlsjonas]

Is your feature request related to a problem? Please describe.
We decided to use a fallback strategy to limit the amount of duplicate translations for similar languages in our application, this means that several country-specific language files are now almost empty (e.g. nl-BE contains only specific overrides on nl).
Weblate is showing a lot of untranslated strings as part of this (and also doesn't seem to have an easy method to remove a duplicate)

Describe the solution you'd like
Allow an option/flag to take into account the base language (i.e. nl) when providing insights for a country-specific variant (like nl-BE).
I believe that this should ideally mark translations as needing verification, and then marking it as translated internally (without adding the key to the country-specific file)

Describe alternatives you've considered
Using secondary language to at least see them, however the secondary language will depend on which language is being translated, additionally this shows a lot of keys as not translated, which can be confusing.

Additional context

[github-actions]

This issue has been put aside. Currently, it is unclear whether it will be ever implemented as it seems to cover too narrow use case or doesn't seem to fit into Weblate. Please try to clarify the use case or consider proposing something more generic to make it useful to more users.

[jlsjonas]

I believe a lot of projects would work with such a use-case and are currently working around this limitation (there's also several older issues to back this thought up)

As for implementation requirements, I believe this is quite limited:

• ignore flag for "not translated" (needs editing would still show for new source-based entries, translation status would ignore not translated, and only take needs editing into account)
• (ideally) ability to delete a non-source key (saving empty string could/should probably do this)

[comradekingu]

I was going to file this too.
I think marking a translation as a secondary subset of a primary translation would be the first step.
(Either by default, or on a per-project/component basis).
Then strings in the secondary language could be unlocked on a per-string basis.

That way secondary translations only feature strings that actually differ, instead of maintaining two diverging string-bases. (Effort would be better spent improving the basis rather than duplicating it.)

So it really is only the editor that is set up to make a visual difference to the translator.
Either one string could be linked to two fields, and/or any change in the source string for either could invalidate both.

@franco999 What do you think?
Also need someone to chime in for Arabic.

[franco999]

That way secondary translations only feature strings that actually differ, instead of maintaining two diverging string-bases. (Effort would be better spent improving the basis rather than duplicating it.)

@comradekingu I am interested in this way of translation, it would be easier to maintain.
In my case, I am currently maintaining the versions of translations in "Spanish (Argentina)" (my country with its own regionalisms) and "Spanish (United States)" (version as neutral as possible for Latin America), since the "Spanish" version has many strings with regionalisms specific to Spain.
These 3 language versions contain approximately 80% of identical strings and therefore duplicated and difficult to keep updated.

[comradekingu]

@franco999 I think the flag for "read-only" can be utilized.
Adding any translation deemed to be a variant could add a blank translation linked to the targeted translation, and then any translation or opening of a string would undo those?

The point of which is to show a genuine level of translation progress.

[kolaente]

I've just stumbled across this and would also be quite interested in using this.
My use case would be to maintain a "formal" version and an informal one of one language.

[franco999]

@franco999 I think the flag for "read-only" can be utilized.

@comradekingu I don't quite understand, would the "read-only" be implemented in the translation file code, in the application configuration or on the Weblate website? Do you have an example?

[MrPowerGamerBR]

+1, I've also noticed that a lot of projects that supports "language subsets" (example: "Portuguese" to "Portuguese (Brazil)" or "Portuguese (Portugal)") always have a small warning saying "please only translate what it is needed", however it is hard to find what could be changed when the source string is shown in the "source language" (example: English).

So it would be useful if you could setup a custom settings for projects (or components?) where you could setup custom source language for a specific language, so, example: By default all components would use English as its source language, but if someone is translating "Portuguese (Brazil)", then the source language is "Portuguese".

[bschmalhofer]

I would chime in with having the same use case. At the project I'm involved in we have a fairly complete translation for Brazilian Portuguese and a much more incomplete translation for Portuguese. It would be nice if both translations could be merged and only the divergent use of languages would have to be translated for Portuese.

[michael-smt]

[...] however it is hard to find what could be changed when the source string is shown in the "source language" (example: English).

FYI to help with this, it is possible to configure secondary languages in your profile which then are also shown while translating.

[nijel]

There is also #7388 which just got added to our roadmap, but I believe both these cover different topics.

The issue here is to better handle translations into similar languages (pt and pt_BR being a good example) where some strings could be shared.