Skip to content
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

Update Portuguese (pt_PT) language files #709

Closed
wants to merge 1 commit into from

Conversation

alvarogois
Copy link

Updated Portuguese (pt_PT) language files using portuguese community’s
consolidated terms and guidelines for WordPress core translation.

Updated Portuguese (pt_PT) language files using portuguese community’s
consolidated terms and guidelines for WordPress core translation.
@jtsternberg
Copy link
Member

Thank you so much for your PR. As per our contributing guidelines, can you please create pull requests from the trunk branch?

@alvarogois
Copy link
Author

Thanks @jtsternberg. Just to get it straight: I should have forked the trunk branch instead of the master, before commiting the files and making the pull request, right?

@jtsternberg
Copy link
Member

@alvarogois thank you for asking/clarifying. Yes, that's right. The trunk branch is the development branch, and is always ahead of the master branch. For that reason, we don't accept PRs against master, as that branch is generally outdated.

When you fork the repo, you'll have access to all the branches, so you would just create a new branch off of trunk, make your changes, commit, then submit that branch as the Pull Request. Hopefully that helps clarify.

@pedro-mendonca
Copy link
Contributor

Hi @alvarogois and @jtsternberg ,
If you don't mind, I suggest you to use a new branch for localization, rebased on top of trunkbranch. That leaves trunk free for string debugging and other parallel PRs.

Another doubt on this:
I do keep my localization branch for cmb2, but I see that if I push it to your repo it will become overlaped by Transifex pulls, so the translations contributed directly here go to trash. In this case, as some others, the translations from Transifex don't comply with the core translation teams guidelines and terms, and that's why @alvarogois is making this translation. What happens next? Will this be kept or overlaped by Transifex contributions?

@alvarogois
Copy link
Author

Good question @pedro-mendonca. Thanks.

@jtsternberg
Copy link
Member

I have to admit, I'm pretty ignorant when it comes to translation and transifex vs core translation guidelines. @fxbenard helped me get setup with transifex/wp-translations. Maybe he will have some valuable insight.

@jtsternberg
Copy link
Member

In the case of this translation, I believe I can merge this (well this being the new PR against trunk), then do a push to transifex so the translation gets saved there as well.

@alvarogois
Copy link
Author

@jtsternberg, Transifex doesn't follow a community approval system, therefore does not apply the locale guidelines for WordPress core translation. It's very demotivating to be contributing to the translation on a platform where these rules are not followed, and therefore where there is no consolidation of terms and a permanent and continued work of a very involved community, which is what happens in translate.wordpress.org. Transifex was important when there was no open platform for collaborative translation of themes and plugins. Right now, for me, it only makes sense if the theme or plugin is not in the repo.

@jtsternberg
Copy link
Member

@alvarogois That's helpful and useful information. I would love to spend more time looking into the proper way to do this, but will have to wait a bit. In the mean-time, what is your recommended solution? Only accept PRs here? Is there a way to pull translations from translate.wordpress.org?

@alvarogois
Copy link
Author

CMB2 has a plugin version in translate.wordpress.org, if the .pot is the same, the translation should be handled there and pulled to the library git repo. As to a way to pull translations from translate.wordpress.org, I'm not aware. Maybe @pedro-mendonca can add to this. He's a Portuguese pt_PT GTE, like me, and he was ahead of the plugin's pt_PT translation.

@jtsternberg
Copy link
Member

Ok, so based on info here: https://translate.wordpress.org/projects/wp-plugins/cmb2/language-packs

Looks like we can remove the translations which already exist there? Is that what this PR is, from there?

@jtsternberg
Copy link
Member

@alvarogois
Copy link
Author

Not exactly. @pedro-mendonca translated the plugin, I used CMB2 as a library for a project and was not sure if the two versions had the same strings. I translated it independently from his version, but they're very similar, we work together as WordPress Portuguese pt_PT translators and GTEs. If the language files are the same, the one there should indeed take precedence: https://downloads.wordpress.org/translation/plugin/cmb2/2.2.2.1/pt_PT.zip

My goal was to overwrite the Transifex version, which was the one here in the library, and has a lot of errors.

@jtsternberg
Copy link
Member

I'll be removing the languages for which there are already language packs, so a PR is probably unnecessary. I learned a lot from this, so thanks for all of your input.

@alvarogois
Copy link
Author

But, if you remove the language files from this library, it won't be translated if anyone includes it in a theme or plugin, right @jtsternberg?

@jtsternberg
Copy link
Member

Ah, that's probably right. Do you think you'd be able to test/confirm that theory?

@alvarogois
Copy link
Author

Tested. If I remove the language files from the CMB2 library on my plugin, CMB2 UI isn't translated anymore.

screenshot 2016-08-17 16 26 24

@jtsternberg
Copy link
Member

Ok, then sounds like we're back to the recommended solution above, which is to periodically update the translations in the repo with what is in translate.wordpress.org, and only pull changes from transifex for languages that are not on .org. Ugh.. doesn't sound fun.

@pedro-mendonca
Copy link
Contributor

pedro-mendonca commented Aug 17, 2016

Hi @alvarogois and @jtsternberg,

There are several issues here.

One is the Transifex situation, as @alvarogois mentioned above, was important before the existence of translate.wordpress.org, but now the plugins should migrate if want to have translations kept by the same community that maintains local WordPress translations. I would keep the work done but migrate it to wp.org system.

Another issue is the actual state of the plugin in the wordpress.org site. As you can see here CMB2 don't have an active column for Stable translation. That is why @alvaro isn't receiving automatically any translation from the repo, because it already existis, partially, as you can see in the Developmentcolumn. I don't know now what is missing to allow it, but as soon as you unblock this, the translations will be available, you can import them from your current .po files, or rely on local translation teams to maintain them for you. I would ping the ones on Transifex team, if they are of trust or connected to local translation teams.

If you want, or trust anyone in particularly, maybe you can keep the translation files here as a backup, but from 4.6 beyond, the priority is the translations that come from the wp.org repo. If a language is 95%+ complete in the repo, every user will receive it's language pack, despite having or not a .po file with that language in the /languages folder.

@alvarogois
Copy link
Author

I just realised the library has a LOT of locales. You should probably move all the language files to translate.wordpress.org. Do you have a way to reach current translators in Transifex? They could be contributing to the plugin's translation in wp.org and it would be easier for you to pull the files from one place only. Maybe reaching other GTEs you can get some help, since CMB2 isn't exactly an uknown plugin/library: https://make.wordpress.org/polyglots/?resolved=unresolved

@pedro-mendonca I'm not sure if WordPress will fetch the translation files form translate.wordpress.org if CMB2 is used as a library inside a plugin or theme. What do you think?

@pedro-mendonca
Copy link
Contributor

Good point. I can't test it as there are no translations on Stable repo branch.

Still, the translations can always be pulled from wp.org repo, better than from transifex, for consistency with core translations and maintenance purposes.

@pedro-mendonca
Copy link
Contributor

I do support some plugins translations both in wp.org and github. Some authors moved completely over wp.org and removed completely the .po files. Still in these cases I keep my own branch for future reference. For those who also keep the .po/.mo files in GitHub I keep contributing, but since wp.org I also import it there, it's redundant, but it's dev/author's call. I just try to keep pt_PT as good as I can and check it with language team (@alvarogois :p ).

So for now I would check how to move everything to the correct repo, and maybe later decide wether or not keep local files, as in 4.6 they are overlapped by repo language packs. If you can get the same good translation support on wp.org as you've had so far, and if cmb2 have any issues loading languages packs while being used as a library, maybe you can pull/update them once in a while from wp.org. Specially because not every good translator is comfortable using github :)

Regards
Hope I've helped a bit

@fxbenard
Copy link
Contributor

As far as I know I never ask Transifex translators to move over wp.org. It took a lot of time to build this community. TX is so much better than GP. We're an alternative community. Pulling from wp.org to TX can be done with a simple grunt task as well ;)

@alvarogois
Copy link
Author

Not my experience @fxbenard. The platform may be good, but the fact that translations get override by users that don't comply with standards and guidelines of the local community ruins it. Besides, IMHO it makes no sense to have duplicated translation flows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants