Skip to content

Workflow

Jump to bottom Edit New page
Stefan Plewako edited this page Jan 31, 2017 · 6 revisions

General

We are trying to translate continuously and review translations change by change.

We have learned over the years that using bulk translation tools (like Pootle and Pontoon) focused on completeness and not quality (like 100% as a goal) is bad for us in the long term. That doesn't mean that everything must be done by hand but hiding valuable information from localizers (including translators hiding these from testers/QA) is considered harmful. Our main goal is to provide great localizations and it is a never-ending process.

In order to simplify things for new contributors we use GitHub (because it doesn't limit us in the same time).
Reporting a bug, discussing and correcting it could be done solely via browser on github.com website.

Resources

GitHub

We are working mainly using Git and GitHub these days. Everything important should be mirrored under our teams GitHub organization.

Getting started

  1. Login to GitHub.
  2. Find what you want to change in our repositories.
  3. Add translation, fix an error or make some other change to the file by clicking Edit this file pencil button in file header.
  4. Save your work with descriptive summary (examples) by clicking Propose file change button on the bottom.
  5. You can add more details about proposed change in just created pull request.
  6. That's it, just watch for GitHub notifications in case someone may have questions about proposed change.

Reporting bugs

If you are unsure about the change, you can always open an issue for the particular repository or for the team repository (if it is more general and/or applies to more than one repo).

Continuous work

If you don't yet have direct write access to repository or don't want to use Mercurial (hg) and tools like git-cinnabar (offers a way to directly work on Mercurial repositories with Git), you can try the setup prototyped in pull#84 to avoid creating pull requests all the time and automate changes integration for maintainers.

  1. Fork https://github.com/aviarypl/mozilla-l10n-pl
  2. Clone https://github.com/aviarypl/mozilla-l10n-pl
  3. Change push URL from original repository to fork (git remote set-url origin --push --add git@github.com:USER/mozilla-l10n-pl.git replacing "USER" with your GitHub username) and enable fork overwriting (git config remote.origin.push '+:').
  4. Make changes, push to fork.
  5. Create pull request, name it like "Continuous integration pull request for @USER" (replacing "USER" with your GitHub username) and in the description add a link to this page. (example)
  6. Report that pull request to stef.

Since git pull --rebase should be used for getting changes by default (and git pull --rebase && git push for pushing), there shouldn't be any real differences (from contributor perspective) between writing directly to original repository and pushing to such persistent pull request.

Advantages for integration: ability to wait for human resolution for changes that potentially break sync between Git and Mercurial (conflicting, unsynchronized, merges?) and much easier implementation.

With setup as above (including remote.origin.push = +:) git pull --rebase will overwrite local changes if they were pushed to fork/PR. Such pull behavior may be surprising and with default forced pushes it may lead to data loss (if the changes from fork/PR were not integrated into main repository yet) but I'm not sure how likely it is and if this is really a problem (please report if it is).

Possible next steps if this would real issue:

  • find out if it is happening with latest Git
  • find a way (config?) to prevent such pull from overwriting pushed changes
  • make data loss less likely by shortening the time between pushing the changes to fork/PR and pushing into main repo (up to 1h initially), possibly by subscribing to GitHub events
Add a custom footer
Add a custom sidebar
Clone this wiki locally