Hello, could you please provide the upstream bugstracker for this project and where the source code is available?

I see @csnyder has a Fedora account, but not jsefler@redhat.com , could you please add him/her here?

thanks a lot,

Re source code - Chris will be able to provide it.

Re jsefler. I can see that he's got a fedora Zanata profile: https://fedora.zanata.org/profile/view/jsefler?dswid=3D-2064=20

My understanding is that to have that profile you need to have a Fedora account too. But I may be wrong. Please is there anything else needed from John?

Thanks, L

Maybe he never connected to Pagure and that's the reason I can't see him here?
Could you please provide answer to the questions so we can start migration?

Thanks for your help!

John, please can you confirm

Thanks, L

It's time to make some progress on this migration. Here are the players:
jsefler@redhat.com QE https://pagure.io/user/jsefler
csnyder@redhat.com DEV https://pagure.io/users/csnyder
nmoumoul@redhat.com DEV (no pagure account yet)

Account created^

kind remember:

could you please provide the upstream bugstracker for this project and where the source code is available?

@jibecfed The Candlepin source code is at https://github.com/candlepin/candlepin and the bugtracker is at https://bugzilla.redhat.com. To create an upstream bug select:
- Classification: Community
- Project: Candlepin
- Component: candlepin

@jibecfed Hi, thanks for creating the Candlepin project in weblate. Can I get admin privileges on that to be able to do more setup? We plan to do the move to weblate as soon as possible.

you are now admin of: https://translate.fedoraproject.org/projects/candlepin/

Question @jibecfed - Zanata has a concept of versions that the candlepin, subscription-manager, and syspurpose projects used to associate with different branches of their github projects. Does this concept also exist in weblate? It looks like the candlepin project that you configured in weblate is associated only with its master branch. If the concept of versions does not exist in weblate, then I think we will want to create individual projects for each branch. E.g "subscription-manager - RHEL8.3", "subscription-manager - RHEL8.2", "candlepin - master", etc. What is your advice?

@jsefler I think what we probably need is to have different components (under the candlepin project) for each branch: https://docs.weblate.org/en/latest/user/basic.html?highlight=project%20vs#project-structure

Yes, it is the right way to do it, see Cockpit for example: https://translate.fedoraproject.org/projects/cockpit/

Weblate handles it nicely for both translators and developers

Thanks - agreed! Therefore I think @nmoumoul should exercise his new admin privileges and rename his current component https://translate.fedoraproject.org/projects/candlepin/candlepin/ to https://translate.fedoraproject.org/projects/candlepin/master/

Kind advice: do not rename components. It will create complexity for you.

Suggestion if the name matters a lot to you: merge change, lock component, delete it and create a new one.

Hi @jibecfed Subscription-manager can be found at https://github.com/candlepin/subscription-manager. In that repo there is a folder from the top level of a checkout called "syspurpose". Therein one can find syspurpose. Similar to Candlepin the primary bugtracker we use is at https://bugzilla.redhat.com. To create an bug for subscription-manager or syspurpose select:
- Classification: Red Hat
- Product: Red Hat Enterprise Linux (8/7)
- Component: subscription-manager

Is there anything else you need from me?

Thank you very much for your help on this!

@csnyder : now that you are admin in https://translate.fedoraproject.org/projects/candlepin/ please add yourself the components "subscription-manager" and "syspurpose".

I suggest you to add the same addons than the ones in https://translate.fedoraproject.org/addons/candlepin/candlepin/

Thinking out loud because it looks like @jibecfed has set up only one weblate "candlepin" project to be shared for candlepin, subscription-manager, and syspurpose translations (and all the branches of each). This deviates from the Zanata model where candlepin, subscription-manager, and syspurpose each had their own individual projects. Clearly he did that because projects candlepin and subscription-manager share the same parent github location https://github.com/candlepin.

If we are going converge management of the three Zanata projects into one Weblate project and use Cockpit as an example https://translate.fedoraproject.org/projects/cockpit/ for how to handle branches, then I suggest the weblate component names follow a strict syntax like <subproject>_<branch>. For example:
candlepin_master
candlepin_candlepin-2.9-HOTFIX
subscription-manager_RHEL-8.3
subscription-manager_RHEL-7.9
syspurpose_RHEL-8.3
syspurpose_RHEL-7.9

( On second thought, maybe a forward slash (/) can be used as the delimiter instead of underscore (_) to give the illusion of branched paths <subproject>/<branch> )

Personally, I think three individual weblate projects would be less confusing and it would avoid the subscription-manager/syspurpose admin @csnyder accidentally harming the candlepin components owned by @nmoumoul and visa-versa.

I just created: https://translate.fedoraproject.org/projects/subscription-manager/
both @csnyder and @nmoumoul are admin of each projects

about syspurpose, as it doesn't have its own github repository, why would it be less confusing for you or for translators to have its own weblate project? Spliting just makes it more difficult for translators to find what to translate for your software.

@jibecfed I have a question regarding force pushing the weblate fork. Candlepin master had to be rebased and force-pushed due to an invalid commit, and then the weblate fork had conflicts. I followed (partly) the instructions here: https://docs.weblate.org/en/weblate-4.2.1/faq.html#how-to-fix-merge-conflicts-in-translations and rebased the weblate fork against current master, but weblate will not let me force push on it. I get this error:

fatal: unable to access 'https://translate.fedoraproject.org/git/candlepin/candlepin/': The requested URL returned error: 403

even though I checked out the repo with my weblate token (git clone 'https://nmoumoul:<my_token>@translate.fedoraproject.org/git/candlepin/candlepin/') and am able to run wlc commands locally. Why would that be?

Would an alternative to this be the deletion and recreation of the candlepin component, and then pushing the 3 translation commits that I have locally to it?

Nevermind, I have reseted the component, and locked it, since we'll have to delete and create new with name 'master' anyway.

I just created: https://translate.fedoraproject.org/projects/subscription-manager/
both @csnyder and @nmoumoul are admin of each projects

about syspurpose, as it doesn't have its own github repository, why would it be less confusing for you or for translators to have its own weblate project? Spliting just makes it more difficult for translators to find what to translate for your software.

Thank you for your help with the new subscription-manager project.
Regarding the syspurpose translations, let's let the owner @csnyder figure out how he wants to structure that because I agree with you. Likely, the syspurpose translations should be a component(s) under subscription-manager. I just don't know how csnyder wants to name it.

@jibecfed Hi, I have a question. Is it possible to install a custom addon (if we decided to write one)? And by custom, I mean one that would only be available to our project(s) (because it would be tied to our specific workflow), and not made available to all translate.fedoraproject.org projects.

If it's not open to all translate.fedoraproject.org projects, the answer is no.

If it's open to all translate.fedoraproject.org, then it means it probably is usefull for everyone, then make it upstream: github.com/weblateorg/weblate the dev is really reactive

@jibecfed

Can we get a project open for syspurpose as well?

https://translate.fedoraproject.org/projects/syspurpose/ perhaps?

Thanks

of course, open a dedicated ticket, this one is too long already

you'll end up very soon with no Zanata, please move your projects asap, you have all the required information to do so, if not, talk with @misc to ease communication. This thread is already far too long.