How to get your translations/localization contribution integrated with existing communities

I happened to re-read this fine piece of penmanship today. And in the light of recent incidents figured that it would not be out of place to muse about a few small steps that can get localization contributions integrated with existing communities.

Some preliminary definitions should set the context for the post:

  • Upstream: the catch-all term for the ultimate source of the project – a place where the core contributors put their work into the version control infrastructure and other related bits like bugzilla/issuezilla etc come together to provide some ‘dashboard’ view of the project. In the context of localization, it usually points to projects like GNOME, KDE, Firefox etc whereas distributions like Fedora, Debian etc are considered ‘downstream’
  • Communities: existing special groups, generally organized around locales who handle the translations/localization of content for the upstream and downstream projects
  • Contributor: in this particular instance it would be the person who has demonstrated interest in contributing localization work for the particular language community

Now comes the short and sweet list of things ToDo:

  1. Discuss and declare your intent to contribute in a public forum – the teams working on l10n are pressed for time since they have to juggle around the string freeze deadlines for a variety of projects. And, since most teams / language communities are made up of a small number of people, there exists a tacit understanding towards tasking. Discussing the intent to contribute in any of the public forums makes it easy for the members to allocate tasks to you
  2. Study the community – most of the members for the language community have been working together in tandem for a long time. Thus, they have a well oiled mechanism to handle the deadlines of the project. Studying how the members interact over mailing lists and / or IRC would provide pointers as to what could be construed as constructive and what is ‘being smug’
  3. Contribute work incrementally – it is always better to start off with small chunks of localization content. That allows the members to review the work and provide pointers in addition to that being a ice-breaker
  4. Acknowledge reviews – the language teams have in-place language consistency standards, processes and guidelines. Acknowledging the reviews and incorporating elements from such guidelines makes for better working relationship
  5. Review work before submission – this shows that you care about the quality of your work and take pride in being a part of the team. The small bits that are required to be reviewed are generally constant and can be converted to a check-list
  6. Update your work status – that helps the ‘leader’ of the language team to assess progress of work and also put in place small tweaks towards meeting deadlines and goals
  7. Get legal clarity – if your employer / employment contract requires you to use a particular ID or provide some extra credit, please ensure that this is discussed upfront with the team and all issues are discussed towards mutually agreed upon clarity
  8. Learn the basics – take time to learn the basics of
    • Version Control Systems of the upstream project(s) you will be contributing to
    • Usage of IRC
    • Usage of mailing lists
  9. Expect and accept rejection – there may be multiple reasons as to why your intent to contribute to a particular project may be rejected. And instead, you could be pointed to some other project that the language team is also working on and asked to contribute. There could be number of reasons for that. Expect such events and accept them.
  10. Being a good contributor begins with being a good citizen (a phrase I borrowed from Pradeepto). And, that starts off with small steps.

    [Thanks to Richard W Jones for his initial page]