Idea: Load languages delta

[maximejobin]

From my understanding, a language is loaded in order of preference.

So if my preferred language has a translation, that translation is used.

In our case, we use fr-CA. But the most up to date language in French is fr-FR (bigger community and more active). It is also important to note that most plugins (almost all) are coded in English.

Let's take plugin XYZ for example:

• Plugin is coded in English (so en-US is always 100%).
• The fr-CA translation is at : 55%
• The fr-FR translation is at: 100%

In our case, fr-CA is our top preferred language followed by fr-FR. As a fr-CA translation exists for XYZ, it will take fr-CA. The fr-FR translation is the discarded for that plugin.

In that case, 45% of the strings showed for fr-CA will be in English (100%-55%) because the fallback will use what's in the code (e.g. __('Hello my friend', 'XYZ); ).

The idea: Wouldn't it make more sense to use 45% of the fr-CA and add the missing 55% from fr-FR. That way, this plugin's translation will be 100% in French. Maybe not 100% in fr-CA but at least it won't show English.

I'd like to contribute to the development if that makes sense. :-)

[swissspidy]

Thanks for raising this issue! It's an excellent question and I totally understand your use case.

In some way this has been discussed in the past and the conclusion was that an automatic fallback and perhaps merge of languages isn't a good idea.

The usefulness of such a feature essentially boils down to how you're using the list of preferred languages.

When my fallback list is e.g. es_ES -> de_DE -> en_US, it would look really weird when half of the UI is in Spanish and the other half in German. And then here and there some English.

However, for fr_CA -> fr_FR -> en_US it's not a problem. Ideally, all your UI is in French. If not, some parts will be in English. But that was already the case when just using fr_CA -> en_US.

Perhaps es_ES -> de_DE -> en_US isn't the very best example, but I'm sure there will be cases where this could lead to weird results. So it's definitely not a one-size-fits-all solution.

However, for all the other cases where it might make sense, we can surely explore this.

(Of course the easiest solution would be to copy over all fr_FR strings to fr_CA if they haven't been translated already.)

Looking at the code I think this could be achieved programmatically rather easily. I haven't tested it, but 4c78495 is what I had in mind.

[maximejobin]

I guess you are talking about the WP administration section.

It seems to me like it makes no sense for the website (front-end) to display in Spanish, Deutsch and English at the same time, no ? Maybe I'm missing something.

My suggestion was only for the front-end... but it wasn't clear as I did not mention it.

[swissspidy]

I was referring to both :-) After all the plugin works on both sides

It seems to me like it makes no sense for the website (front-end) to display in Spanish, Deutsch and English at the same time, no ? Maybe I'm missing something.

My suggestion was only for the front-end... but it wasn't clear as I did not mention it.

No I'm not sure I follow 🙂 The two sentences contradict each other. Your suggestion was for the front end but it doesn't make sense?

[maximejobin]

Let me clarify!

In what case would it make sense to have such fallback: es_ES -> de_DE -> en_US ?

it would look really weird when half of the UI is in Spanish and the other half in German. And then here and there some English.

It is already going to be weird if plugin A is only translated in es_ES and plugin B is only translated in de_DE. Right ?

Maybe my proposal could be applied only it they all come from the same language.

In the Dashboard, I might prefer fr_CA -> en_USas a translator. But on the front-end of the website, I can't see a use case where I'd want the website to be half in fr_CA and half in en_US instead of taking as many strings as possible from fr_CA and filling, for instance, the missing strings with fr_FR or fr_BE.

Is is clearer ?

There could be an option to apply or not the delta. :-)

[swissspidy]

In what case would it make sense to have such fallback: es_ES -> de_DE -> en_US ?

As I said in #41 (comment), it isn't the best example. I tried to exaggerate to prove a point. A more reasonable problem could be something like roh -> it -> de_DE -> en_US. Still the same problem though.

It is already going to be weird if plugin A is only translated in es_ES and plugin B is only translated in de_DE. Right ?

That's true 🙂

There could be an option to apply or not the delta. :-)

Yeah, since this really depends on the context, this couldn't be done automatically for everyone. I'll experiment with adding a filter that one can use if they want this delta to happen in that specific scenario.

Sounds good?

[maximejobin]

Sounds perfect!

[swissspidy]

@maximejobin Curious, have you ever tried my attempt at this (4c78495) on a site? Maybe it's time to revive it 🤔

[maximejobin]

No, I did not test it. I did not know you made that patch. Let me see if I can find a site with incomplete translations to test that use case.

[swissspidy]

I've linked it in one of my earlier comments, but it's easy to miss, so no worries 👍

I just opened #249 to track this more easily, as I am not sure if it had a bug.

Also, I obviously will need to fix merge conflicts.

[swissspidy]

Closing this for now as there will be a preferred_languages_merge_translations filter in the next release to allow handling this scenario.