Re: Translation updates through gitlab?



Hi Jehan,

There are several teams that don't use Damned Lies' workflow, relying it on malining list, for example, so using MRs is an option.

But you cannot forget about DL at all because PO file in your repository are not valid for translation. I mean, those PO files are static, they are not automatically updated with new strings added to source code. That's part of the magic of Damned Lies :-)

The PO file you download from DL is not a direct link to PO file in git: i'ts generated using some tools that read POTFILES and other files and extract translatable strings to generate an up-to-date PO file. Of course you can do that process manually, but maybe it makes no sense to duplicate efforts.

Another question is: who will review those translations? You should encourage every translation team to use that new workflow, and opening that door can be "dangerous": most of the coordinators won't accept modifying their workflow, because it simply works. Having two ways to receive/review translations (gitlab's MR and DL) can be a pain for those who have to review and approve them. And you should speak several languages to be able to review all of them ;-)

Also note that every team has it's own rules: usually there is a team coordinator that approves commiting translations into git. "Plain" translators usually not have that power, so accepting translations directly from translators might cause problems in the translation team.

Just my 2 cents, maybe other people have a different idea, and it's of course acceptable.

Regards.

El mié., 1 abr. 2020 a las 21:13, Jehan Pagès via gnome-i18n (<gnome-i18n gnome org>) escribió:
Hello everyone!

Lately we have had some people uploading GIMP translations in the form of merge requests on gitlab.

Notably we had someone who uploaded big po files updates for Korean, a year ago:
For GIMP 2.10: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/51
For master: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/54

He did update a lot of translatable text. Unfortunately he was not responsive on gitlab when we (as well as the Korean team coordinator) asked him to send his po file through the team channel, even after we tried to discuss with him in English or Korean. No idea why. He was capable enough to translate hundreds of sentence from English to Korean, use git and make gitlab MR, but he would not answer. In the end, we just had to close the MR without taking the changes in, which was a bit heartbreaking (never nice to waste contributor's hard work, especially as Korean is not updated that often unfortunately!).

Recently, after a year, the same person reopened a new MR, and again without answering or following procedure:
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/213

Also recently someone also opened a MR for zh_TW and he doesn't answer much either (though there was only one comment, so I made a new one and will wait a bit before closing). Don't know what's up with translators making MRs and not following up!
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/206

Anyway bottom line: I am wondering if there were a way to improve the procedures for translation reviews made through MR? I mean, these translators definitely could improve their contribution skills by actually reading/answering comments and following up, but the base idea is still right. The po files are on our repository so I understand why an outsider might think making a MR makes sense. Of course if it ended up that the translation was not right, if the translation needed changes before merging, with a non-responsive person, the end result might be the same. That's a problem anyway. But maybe it could have just worked out without changes?
So yeah, I'd be happy to work more closely with translators team willing to review translations in gitlab.

Am I missing something?
Thanks everyone!

Jehan

--
_______________________________________________
gnome-i18n mailing list
gnome-i18n gnome org
https://mail.gnome.org/mailman/listinfo/gnome-i18n


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]