Betaflight-configurator: portuguese variants and fallback

[Docteh]

Hi, in #team_translation on slack there is discussion on Portuguese language. Discussion is most likely on slack, just planting an issue so there is one.

Splitting up two dialects pt-BR and pt-PT was mentioned, and also tweaking the fallbacks

https://www.i18next.com/principles/fallback

so we could do like

fallbackLng: {
    'pt-BR': ['es', 'en'],
    'default': ['en']
}

Just remember to eventually fall onto en locale for this project.

Or maybe this gets done in crowdin

• [ ] Do this via crowdin?

[McGiverGim]

As @leocb asked in Slack, I have been looking at that.

• In Crowdin can be done, it seems there is an option for this:
  
• The localization in i18next can do the same, fallback from the dialect to the primary language.

So we have both ways to do this, but both have the same problem: they need to add the language in Crowdin to let the translator change the needed phrases and nothing stops the users to start translating them, all the phrases, because it only sees that the language is empty and needs translation, so we can end with two totally different translations for two very similar languages. I don't know how to solve that.

[mikeller]

I can see how the tendency of getting two separate translations is not ideal, but I think this is something we have to live with if we decide to split languages. The benefit of setting them as mutual first fallbacks is that messages that are missing in one but not the other language will fall back to a different version of the same language, which is a better approach compared to falling back to English, so it's a win.
Not sure if It's probably better to define the fall back programmatically in the source code than to do so in Crowdin, as this makes it more obvious.

[leocb]

Hi, thank you all for taking a look at this :)

I agree on making the fallback on the code. But I'd first verify if activating that setting on Crowdin makes the fallback more obvious for the translator (as in the translator can see the fallback string when translating). If so, fallback on Crowdin would be preferable.

On the subject of two separate translations. I agree it's not ideal. If that Crowdin setting doesn't show the fallback string, then we'd have to make it obvious for new translators that they don't need to translate everything in pt-pt, maybe leave an unused string on the locales file with that warning? I dunno.

Anyway, here's my suggestion:

• pt-br -> pt-pt -> english
• pt-pt -> pt-br -> english
• Change the current available translation to pt-br (as I'm the main maintainer for that language) and leave a new pt-pt language open for changes.

If @PIRATES3D, @feiticeir0 or @AlexGaroa are still around and could chip in on this, that'd be greatly appreciated :)

[McGiverGim]

@leocb I don't think Crowdin helps with that... I don't think they show the fallback string, I think they only complete the language file when downloading it with the primary language phrases for dialects (but I have not tested it).
And it only works for dialect/primary, not for dialect/dialect, so the only option is to do it in code in the Configurator.
But as we commented, in Crowdin they will be treated as two different languages and the translators will see them in this way.

[leocb]

Let's test it with on crowdin with pt-br as primary and pt-pt as a dialect. If there's not much difference on Crowdin, then I guess it'll make more sense to enable it on code only and disable on crowdin

[McGiverGim]

No, we can't do it in this way in Crowdin. The primary will be pt, and the other two will be dialects. Both dialects will fallback to the pt primary.

[Docteh]

can the language be changed? like change pt to pt-PT or pt-BR or is that no good? I see in their list they have pt-PT and pt-BR but in the _locale files we have pt

[leocb]

@McGiverGim Ahh I understand it now! Seems good to me, can we test it?

[McGiverGim]

@Docteh the problem is that Portuguese only have PT language because in theory, since some time ago, both dialects were unified into only one language. Users from both dialects have been working to do a translation valid for both. But it seems that there are some cultural differences that make this nos possible with the quality they want, so they ask to add the dialects.

@leocb what is the final desired result? To have PT, PT-pt and PT-br? Three languages for Portuguese? You only want the dialects? What happens if a user enters with PT as language, without dialects, what is the dialect that will be selected by default?

[leocb]

Yes, what McGiverGim described is exactly what happened. For example: some terms were left untranslated due to root cultural differences, both translations were right, but one didn't work for the other simply because, albeit correct, we use different terms on our daily lives.

now answering @McGiverGim:

I don't know how the setup would work on crowdin, but three versions is not desired.
This is the desired result:

• br -> pt -> english
• pt -> br -> english
• Change the current available translation to br and create a new pt language.

In this case, as per your comments, I'm guessing this would be configured on the code and not on crowdin, if that's the case, I'm OK with it

[Docteh]

If we can't rename languages, maybe make new pt-BR and upload the pt-PT translation into it?

I notice that in crowdin it shows pt-PT in the url for Portuguese

[McGiverGim]

Exactly, for Crowdin, it only has Portuguese, and Portuguese Brazilian:

We can create custom languages too, but I don't know if it will let us to create the PT-pt if it is assigned to the Portuguese standard.

So, in the end, I think the easier is:

• Add the Portuguese Brazilian to translate, and upload the same translations than has now the Portuguese.
• Use the Portuguese for PT-pt and the new Portuguese Brazilian por PT-br.
• Modify the Configurator to let custom fallbacks, and make them:
  PT -> PT-br -> EN
  PT-br -> PT -> EN
  If some user enters in the Configurator with the system configured into PT it will go to the PT-pt by default.

@leocb is this ok? If it is, I will need to test the changes in the Configurator, to be sure that it works, before starting the work in Crowdin.

Remember that the translators will not see what translations they need to translate and what not. They will see any new phrase as translatable in both languages. They can look at the "other languages" option to see the other translation, but is a manual operation.

[leocb]

@McGiverGim looks good to me

Can we put a notice somewhere that these fallbacks are in place and warn translators to look in the "other languages"?

Also, maybe we should delete the pt translation after copying it to BR? This would be so new translators are encouraged to change the strings to their dialect. I didn't get any response from the previous active pt translators to get their input on this. I guess I could manually change the strings I've discussed with them in the past.

[McGiverGim]

@leocb I'm not too sure what do you want exactly...

Are you saying that the actual translation must be moved to PT-br and then we must delete the contents of the PT (that contains the PT-pt)?

About the notice, I'm not too sure what is the best place. We can send an email to the actual PT translators registered in Crowdin, but I'm not too sure how to notice the future translators.

@mikeller what do you think about this? Is that the way to go? I don't like to delete the current language, because in this way the future translators will not know why the phrases are empty but they see them translated (the fallback from PT-pt to PT-br is not natural). But in some time, we will have new phrases with this behaviour.

[leocb]

@McGiverGim That's correct. At least that's my ideia to motivate the dialect corrections. I could do those myself, in that case the deletion won't be necessary

[mikeller]

@McGiverGim: I agree with your proposal in https://github.com/betaflight/betaflight-configurator/issues/1827#issuecomment-555903830. And I also don't think that deleting a language, or starting out with an empty dialect is the right thing to do. Yes, there are messages that need to be re-translated, and we want to encourage this. But there are also ones that will be fine (probably a majority), and forcing translators to re-translate those means extra work, and will also lead to less consistency between the translations for things that are not dependent on the dialect, but leave some room for interpretations.

[stale[bot]]

This issue / pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

[McGiverGim]

Sorry, I forgot a little about this... I will try to take this again this week...

[mikeller]

@McGiverGim: Somewhat related to this, we were also talking about adding an 'English' translation in crowdin, and using the translation that is provided with pull request as a second fallback.
This should allow us to get better consistency in English, compared to the current situation where dozens of programmers are contributing parts of the translation.