@mdomonko @ffesti - FYI

of course, your are most welcome!
please share the list of your repositories containing translation files=2E

Rpm:
https://github.com/rpm-software-management/rpm/

Popt:
https://github.com/rpm-software-management/popt

Both are old-school autotools + gettext projects, translations in toplevel po/

should I pup both repo in the same weblate project or are they different so=
ftwares/lifecycle?
--
Jean-Baptiste

Different projects please, popt is a dependency of rpm but different software with very different release cycles.

Hmm. Dnf seems to have translations in different repositories from the software, and we might want to do the same. Is this something we can reasonably change after weblate project creation, or should we do that first?

you can do it in a few months if you wish=2E

Some project have complex merge workflows, deliver translations in package=
s instead of source itself or are afraid by the size of git=2E That's the r=
eason some projects prefer to have a git repository dedicated to translatio=
ns=2E
--
Jean-Baptiste

For us the main reason for a separate repository would be to avoid git history pollution - we certainly do not want automated pushes to the main repo whenever somebody updates a translation somewhere, just manual updates every now and then. This is possible with weblate AIUI - right?

If we can go with a manual sync at the moment and switch to separate repo (possibly with a more automated syncing) then lets go ahead :)

well, common lifecycle is:

• you update pot file each time needed
• weblate update po files and notify translators
• translators do their work in weblate

After a translation is completed or if some changes where done for more than a few days, weblates opens a PR.
As long as the PR is open, Weblates reuses it.

With Git Squash per author activated in your component, this means:

• one commit per pofile to update po with latest pot content (whatever how many pot updates you do)
• one commit per translator contributing to a language

This means the amount of commits isn't that important if you keep Weblate's PR open.
what increase the number of commits is the number of translators, which probably is a good thing to have many.

You may also git squash everything, but you'll loose attribution, which isn't nice for translators.

Ok, thanks for the explanation. We've always done translation updates via big batches (first Transifex, then Zanata and now ... Weblate), so squashing only differs in terminology, not practise. That can change if/when we move to a separate repo for translations, but sounds like this will work for now.

So lets just go ahead with the current repos.

Created:
https://translate.fedoraproject.org/projects/rpm/
https://translate.fedoraproject.org/projects/popt/

I can see multiple branches for RPM. Where would you like the translations to go?
I used master for now.

Weblate can allow us to have any number of branches and smartly propagate the changes from one branch to another. Every branch you still release is interesting for translator.

By the way, the license of POPT looks broken, what is this thing? Please remove: "Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium."

Not doing so may mean you don't comply with standard MIT license, which would be weird. See https://opensource.org/licenses/MIT

If you are not MIT, this means also changes to you package https://src.fedoraproject.org/rpms/popt/blob/master/f/popt.spec#_9

Oh, I forgot to say, on each component you can see the addins I created.
@pmatilai is admin (and can add others)

Automatic update of po files to sync them with pot. In this addin, I removed line numbers to save space (often pot updates impact lines number, which create useless changes).
Automatic update of LINGUAS files.
Automatic addition of contributors in header.
Git squash per author.

This sounds like a fine starting point (translations to just master matches what we had before), we'll fiddle with the details as we learn more about Weblate) Thanks!

Interesting point about popt license BTW, the license was added in 1998 and the file is untouched ever since, and in all that time nobody ever noticed anything wrong with it... We'll look into it, thanks for pointing this out!

I removed line numbers to save space (often pot updates impact lines number, which create useless changes).

But then running update-po (from dist tarball creation) will end up adding those line numbers back, creating different kind of churn. Is the expectation that upstreams disable the line number creation from their makefiles too, or is there a workflow (or something else) that I'm missing?

Other than that, seems to be working fine.

You created git conflicts because of this "update-po". See: https://translate.fedoraproject.org/projects/rpm/master/#repository

Weblate already sync po files with the pot file. You should not have to use it anymore.

Right, new toys need new ways of working, but I did not realize Weblate will require such fundamental changes to the makefiles and workflows, this hasn't been the case with Transifex and Zanata (which certainly had their own annoyances).

as far as I know, everything works fine.

Yes, Weblate is more integrated in dev workflow than side of the road tools such as Transifex and Zanata. It aims to automate quite a lot of uninteresting but mandatory stuff and it is the best open source tool by far.

I hope it suits your project.

Please feel free to reopen if needed.