search

mozilla / multi-account-containers

Firefox Multi-Account Containers lets you keep parts of your online life separated into color-coded tabs that preserve your privacy. Cookies are separated by container, allowing you to use the web with multiple identities or accounts simultaneously.
https://addons.mozilla.org/firefox/addon/multi-account-containers/
Mozilla Public License 2.0
2.64k stars 322 forks source link

Git submodule configuration for l10n is awkward for non-Mozilla contributors to use #2512

Closed gpoole closed 1 year ago

gpoole commented 1 year ago

Before submitting a bug report

Step to reproduce

The configuration of multi-account-containers-l10n as a submodule makes life very difficult for non-Mozilla contributors looking to propose new features requiring translation in a PR, if it's even possible at all. The instructions in the contributors guide say to create a branch and push it to multi-account-containers-l10n, which is not possible without having write access to that repo. It's not clear to me how to go about creating a usable PR that introduces new labels.

Could you please update the instructions to describe the best way to approach this problem or consider changing the architecture of the repo to make it a bit more approachable for external contributors?

Actual behavior

There is no clear correct approach to add features that require new labels.

Expected behavior

There should either be instructions that are usable by both external and internal contributors on the correct approach for introducing new labels, or the architecture of the repo could be modified. For example, the repo could be changed to use git subtrees instead of submodules, which would allow changes to be more easily proposed and merged here then pushed back upstream to multi-account-containers-l10n.

Additional informations

No response

Provide a copy of Troubleshooting Information page (optional)

No response

dannycolin commented 1 year ago

The contributor guide specifically mentions to create a fork then submit a pull request (PR). That means you can't have issue with right access since you're pushing this PR to your own copy of Multi-Account Containers (MAC).

For the submodules, this is something specific to git and not to how Mozilla projects work. Many other projects outside Mozilla use this same pattern. In this case, it does fit the needs of the l10n team who needs to be able to change things without affecting our repo and vice-versa. There's no intend to change that.

It's not clear to me how to go about creating a usable PR that introduces new labels.

You have to add the new strings needed for your patch in _locales/en/messages.json as you would do for any other addons. When your patch is ready for review, you open a PR on this repository for it and another one on the l10n repository for the submodule repository for any changes in _locales. In other words, you need to see _locales as a separated git repository when it comes to submitting codes.

I'm going to close this issue since it isn't a bug but a question on how git works. However, feel free to ask more questions on our matrix room at #containers:mozilla.org. You can find a quick howto to join our Matrix server on https://wiki.mozilla.org/Matrix.

gpoole commented 1 year ago

@dannycolin This is not a basic git usage question, I'm an experienced git user. I understand how to fork a repo and create a PR. The instructions in the contributors guide taken literally are as I said not usable for external contributor, as under the "translations" section they suggest creating a branch, pushing it and creating a PR on multi-account-containers-l10n, which is not possible without first forking it or having write access to the original multi-account-containers-l10n. Since doing this in a workable way at least requires more steps and juggling remotes on the submodule, I think it would be helpful to document those steps for people who haven't come across this before. Whether submodules are commonly used or not, I certainly haven't had to make a cross-module PR before so it seems useful to me to document the exact process.

From what you've said here and looking at other PRs my understanding of a workflow that would work for an external contributor needing to touch src/_locales is:

  1. Fork this repo
  2. Fork mozilla-l10n/multi-account-containers-l10n
  3. cd src/_locales
  4. git remote origin set-url git@github.com:mozilla-l10n/multi-account-containers-l10n.git
  5. git checkout -b message-updates-yyyymmdd
  6. git push -u origin message-updates-yyyymmdd
  7. Open PRs on both projects

Is that right? If so, I think it would help a lot to include steps about how to manage the fork in the instructions, as well as the idea you've mentioned that these can be treated as independent repos, as that was the missing piece for me here.