New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added translation for Brazilian Portuguese #2535
Conversation
Should this translation use the language code |
I agree @prcr , we will change for |
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 |
OK, so perhaps it's simpler at this time to just have a @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! |
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 |
What about zh_CN then? while |
@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. |
Or wait, does lunr know on Python side which languages it supports? We have it all in our own source code here:
Like :
That's what you mean? |
Hi everyone, We would keep this Pull Request in pt_BR, so I updated this to no conflict with the last master commit. Thank's. |
I'm proposing #2602 to address the comments I had |
@@ -103,6 +103,7 @@ supports the following options: | |||
* `fr`: French | |||
* `es`: Spanish | |||
* `ja`: Japanese | |||
* `pt-BR`: Portuguese (Brazil) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these -
should be underscores (_
), right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ops, sorry it was my fault. I made the adjust.
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 |
Oops, sorry about another merge conflict 😵 |
@ultrabug Do you think this one is good to go? I couldn't find any problem with this. |
You are right, keep alphabetic order avoid this kind of merge problem. |
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? $ 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you
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 |
Hi,
This commit is enough?
Best regards,