Develop branch for dataverse-language-packs

[mhvezina]

The content of the develop branch doesn't reflect latest version of language packs as one would probably expect (even the source language, en_US, is not up to date if I'm not mistaken).

Since there is no "develop" version for languages packs I think this branch should be removed or should be kept minimal, maybe with only an up-to-date readme.md file pointing to the latest translation (version branches) for each language represented. Would that be a good idea?

[4tikhonov]

Yes, that's right but we need a clear workflow to manage all translations for different versions. We're working on Weblate as a service to get everything in one place and with CI/CD pipeline to get a proper versions of translations.

It's very difficult to manage this workflow manually even without develop branch.

[pdurbin]

My suggestion would be to first document the branching strategy. As an example, here's how we wrote this up for Dataverse at http://guides.dataverse.org/en/4.19/developers/version-control.html#branching-strategy

The Dataverse branching strategy had a big change a few years ago. (Anyone interested can look at http://guides.dataverse.org/en/4.0/developers/branching-strategy.html for how it used to be.) So it's fine for the branching strategy to change over time. The important thing, in my opinion, is to write it down. 😄

[mhvezina]

Branching strategy for language packs is actually quite simple. As I understand it, there is one branch for each Dataverse version released (tag). en_US locale is then copied here from the original remote branch (e.g. https://github.com/IQSS/dataverse/tree/v4.19). Following that, other locales can be added based on this en_US locale. No need for develop nor master branches. Of course, if we want translators to be able to contribute to latest features still in the IQSS Dataverse develop branch, then we could have a develop branch here as well (but, speaking for myself, I have done most translation work only after Dataverse version is set/released). I'm not familiar enough with Github but can the en_US language pack directory be a submodule pointing to the IQSS en_US directory of the same branch?

[pdurbin]

I'm not familiar enough with Github but can the en_US language pack directory be a submodule pointing to the IQSS en_US directory of the same branch?

I've only pointed a git submodule to an entire git repo. I don't know if it's possible to point to a subdirectory of a git repo.

No need for develop nor master branches.

Don't you need a branch to hold the README, at least? 😄

[mhvezina]

@pdurbin Could the last version branch be the default branch ? Then the README file would be updated there.

[pdurbin]

@mhvezina in theory, yes, but you'd need to switch the default branch every time to make a new branch (a new branch called dataverse-v4.20 in the future, for example). It feels like a lot of switching to me because when people clone the repo, the default branch gets put into their .git/config file like this:

$ tail -3 .git/config
[branch "develop"]
	remote = origin
	merge = refs/heads/develop

So maybe you'd need to tell people to re-clone fairly often? When the default branch changes? That's my concern, but maybe it's ill-founded. 😄

Something else to consider is that the default branch is always the default target for pull requests. This can be changed on the fly but a lot of people will probably just use this default. Maybe this is what you're saying... that you want pull requests to go into the branch for the latest release, ideally (branch dataverse-v4.19 as of this writing).

[skasberger]

My thoughts on this:
The master branch should hold all the latest translations, which are in some way tested or reviewed.

I don't see a need for a develop branch, but a branch for each translation. The branch name should have the information for the language being translated, and for which dataverse version (e. g. aussda_4.18.1. When finished, PR to master, and the PR manager updates the README.md in the master branch (which holds the information of the latest tested changes).
And for the master branch you can create releases, when the lowest version number for each translation is going one up (you can call it least common denominator or minimum requirements fullfilled)

So much about norma git/github workflow. But I dont know about the best workflow to integrate with weblate.:)