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

Please check #2525 for a nice and complete PR reference

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?

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

Hi @ultrabug and @prcr .

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

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

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"). 👍

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

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!

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

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?

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.

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

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! =)

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.

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.

Obrigado (works for both pt and BR) ;)

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

@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...