Added translation for Brazilian Portuguese

[piantino]

Hi,

This commit is enough?

Best regards,

[ultrabug]

Hello @piantino , no it's not enough but you're on the right path

Please check #2525 for a nice and complete PR reference

[prcr]

Should this translation use the language code pt_BR instead, in case another contributor wishes to add the European Portuguese translation at a later time?

[piantino]

I agree @prcr , we will change for pt_BR.
Thank you.

[piantino]

Hi @ultrabug and @prcr .

Update done!
Let us know if anything more is necessary!

[ultrabug]

Thanks mates, please check #2564

There is no pt_BR locale support from lunr.js so this will not get in as-is I'm afraid

[prcr]

There is no pt_BR locale support from lunr.js so this will not get in as-is I'm afraid

OK, so perhaps it's simpler at this time to just have a pt translation.

@piantino, you could even submit this as the Portuguese translation instead of specifying as Brazilian Portuguese, since the only word that would probably be different in European Portuguese is "Buscar" (it's more common to translate "Search" to "Pesquisar"). 👍

[ultrabug]

please have a look at #2565 too, pt_BR might be added without breaking mkdocs anymore if both MR are accepted but the search engine will only work for pt, not pt_BR so I guess it's up to you

[prcr]

Thanks @ultrabug, I think that #2565 makes a lot of sense and will make supporting languages that support the locale territory much more convenient. 🚀

So, I guess it's up to @piantino and @Nibuitoni if they wish to submit this translation as Brazilian Portuguese or just Portuguese. 🇧🇷 🇵🇹 Sorry if I made things more confusing!

[oprypin]

Hmm sorry I haven't followed this in any detail at all. Also I suppose this isn't the exact issue to comment this on, because it's a more general decision.

But to me it appears very clear that ideally we'd be able to specify pt_BR while also being able to give pt to the search plugin if that's what it wants.

[ultrabug]

But to me it appears very clear that ideally we'd be able to specify pt_BR while also being able to give pt to the search plugin if that's what it wants.

What about zh_CN then? while pt is supported by lunr, zh is not for instance

[oprypin]

@ultrabug Then it seems like a manual mapping is needed. Or wait, does lunr know on Python side which languages it supports? In that case try-except with decreasing verbosity might be possible to apply.

[ultrabug]

Or wait, does lunr know on Python side which languages it supports?

We have it all in our own source code here:

mkdocs/contrib/search/lunr-language
├── lunr.ar.js
├── lunr.da.js
├── lunr.de.js
├── lunr.du.js
├── lunr.es.js
├── lunr.fi.js
├── lunr.fr.js
├── lunr.hu.js
├── lunr.it.js
├── lunr.ja.js
├── lunr.jp.js
├── lunr.multi.js
├── lunr.nl.js
├── lunr.no.js
├── lunr.pt.js
├── lunr.ro.js
├── lunr.ru.js
├── lunr.stemmer.support.js
├── lunr.sv.js
├── lunr.th.js
├── lunr.tr.js
├── lunr.vi.js
└── tinyseg.js

In that case try-except with decreasing verbosity might be possible to apply.

Like :

• try the language + territory first (pt_BR) -> if present, no log
• else try the root language (pt) -> if present, INFO
• else default to english -> WARN

That's what you mean?

[piantino]

Thanks @ultrabug, I think that #2565 makes a lot of sense and will make supporting languages that support the locale territory much more convenient. rocket

So, I guess it's up to @piantino and @Nibuitoni if they wish to submit this translation as Brazilian Portuguese or just Portuguese. brazil Portugal Sorry if I made things more confusing!

Hi everyone,

We would keep this Pull Request in pt_BR, so I updated this to no conflict with the last master commit.
So, we will wait for #2564 and #2565.

Thank's.

[ultrabug]

I'm proposing #2602 to address the comments I had

[oprypin]

I think these - should be underscores (_), right?

[Nibuitoni]

Ops, sorry it was my fault. I made the adjust.

[oprypin]

Could you merge master branch again?

@ultrabug Seems like we should exclude foreign language files from English spelling checks (codespell) 😄

But the PR authors can ignore that check

[piantino]

Could you merge master branch again?

@ultrabug Seems like we should exclude foreign language files from English spelling checks (codespell) smile

But the PR authors can ignore that check

@oprypin merge done! =)

[oprypin]

Oops, sorry about another merge conflict 😵
As a note for how to resolve it: the order of locales in the doc should be kept alphabetic.

[oprypin]

@ultrabug Do you think this one is good to go? I couldn't find any problem with this.

[piantino]

Oops, sorry about another merge conflict dizzy_face As a note for how to resolve it: the order of locales in the doc should be kept alphabetic.

You are right, keep alphabetic order avoid this kind of merge problem.
A fixed it and squash the commits.

[oprypin]

I strongly prefer that the squashing didn't happen. That drops all review history (both in terms of information and for keeping track of what's already reviewed) and has 0 advantages. And weren't there multiple authors in these commits?
If you'd be up for it, could you please undo the squash and instead push another merge commit. Starting with:

$ git reset --hard 20f202d1b73e69e8987433508f93aba6d116641e   # last non-forced commit

[piantino]

I strongly prefer that the squashing didn't happen. That drops all review history (both in terms of information and for keeping track of what's already reviewed) and has 0 advantages. And weren't there multiple authors in these commits? If you'd be up for it, could you please undo the squash and instead push another merge commit. Starting with:

$ git reset --hard 20f202d1b73e69e8987433508f93aba6d116641e   # last non-forced commit

I tried to organize the commit messages but I forgot the impact of squash, sorry for that.
Merge done.

[oprypin]

Thank you

[ultrabug]

Obrigado (works for both pt and BR) ;)

[ultrabug]

I was about to merge, but now I'm confused about #2615 ?

[oprypin]

@ultrabug Ah that's clearly some accident after the complicated branch manipulation. We can ignore that

[piantino]

@ultrabug Ah that's clearly some accident after the complicated branch manipulation. We can ignore that

@ultrabug I made some mistakes, I thought that was in my repository...