Clone this wiki locally
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.
- Aviary.pl team repositories
- Mozilla l10n files backlog
- Report bugs in the team repository issues (if the problem is more general and/or applies to more than one repo)
- or in individual repository issues
- we tend to use English but in general use the same language when replying
- creating issues or starting discussions in Polish is OK
- Search dictionaries and existing translations
- community-poland mailing list
- Aviary.pl IRC channel
We are working mainly using Git and GitHub these days. Everything important should be mirrored under our teams GitHub organization.
- Login to GitHub.
- Find what you want to change in our repositories.
- Add translation, fix an error or make some other change to the file by clicking Edit this file pencil button in file header.
- Save your work with descriptive summary (examples) by clicking Propose file change button on the bottom.
- You can add more details about proposed change in just created pull request.
- That's it, just watch for GitHub notifications in case someone may have questions about proposed change.
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).
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.
- Fork https://github.com/aviarypl/mozilla-l10n-pl
- Clone https://github.com/aviarypl/mozilla-l10n-pl
- Change push URL from original repository to fork (
git remote set-url origin --push --add firstname.lastname@example.org:USER/mozilla-l10n-pl.gitreplacing "USER" with your GitHub username) and enable fork overwriting (
git config remote.origin.push '+:').
- Make changes, push to fork.
- 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)
- Report that pull request to stef.
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