Web Translation Details
This is a detailed description of translation processes for the GNU website, so everyone can quickly get the picture of how things are done and the amount of work that is needed to get them done.
Introduction
The GNU website has thousands of documents, most of them philosophical articles and technical documents which need to be translated to get them available to a broader audience, so everybody around the globe can benefit from them. Dealing with the task of translating a website this large is a hard job, and too often people volunteering translations get frustrated or loose interest in keeping up with that work.
Web Translators
Translators should work on translating web pages according to the GNU Web Standards designed by webmasters and sysadmins at GNU. Among many other things, this means that the following guidelines should be strictly performed:
- Don't mess with the original HTML layout. Usually, GNU webmasters spend a lot of time designing the web pages and not keeping the HTML from translations as close as possible to the original is troublesome.
- Don't use visual editors, use plaintext editors instead. Otherwise, it's very difficult to be sure that previous guideline is achieved. Moreover, visual editors used often add extra HTML tags and sometimes they refer to non-free software.
Please, see also how to join a web translation team.
Updating to the new style
The new style of the gnu.org website relies on SSI (Server Side Includes) which makes it easy to propagate important changes to all pages, as well as maintain a uniform look & feel. It is easier for translators, because they deal with less markup. To update your translations you have to translate the “templates”:
- Copy /graphics/topbanner.svg to /graphics/topbanner.LANG.svg where “LANG” is the language code. Edit the file with Inkscape or with a plain text editor such as GNU Emacs, translating “GNU Operating System”. Then with Inkscape, save the file as /graphics/topbanner.LANG.png (File -> Export Bitmap…). Then open the PNG image with the GIMP and flatten it (Image -> Flatten Image). Don't forget to save and cvs add the files — this applies to all new files, of course.
- Create a style.LANG.css in the root. Normally, you would
need only one line in it,
namely
#logo{background:url(/graphics/topbanner.LANG.png) no-repeat;} - Translate /server/header.html. Basically this means substituting the attributes “xml:lang” and “lang”, specifying the proper encoding and inserting the appropriate line as per this note.
- Translate /server/banner.html, /server/footer.html
and /server/footer-text.html.
In /server/banner.LANG.html, you have to import your CSS
style on the third line, for example:
<style type="text/css" media="all"> @import url('/style.css'); @import url('/style.LANG.css'); </style> - Adjust the markup of your translations to be valid XHTML and add the appropriate directives.
If you are updating from the previous SSI-fied look with the sidebar, note that these files under /server are no longer needed and can be deleted: style.LANG.css (if any), footer-short.LANG.html and footer-min.LANG.html (provided that you change all your pages not to use them), sidebar.LANG.html, sidebar-bottom-half.LANG.html, sidebar-fsf-support.LANG.html, sidebar-short.LANG.html, sidebar-min.LANG.html, sidebar-stay.LANG.html, sidebar-bottom-half.LANG.html.
Web Translation Teams
Each language present on the GNU website should have a team, however some translations were volunteered by people who didn't want to take charge of a team; hence, the lack of teams for some languages present. Teams provide the context for a group of people with common objectives, i.e. translating the GNU website into a known language to all team members. Each team has at least one leader (or admin) that will be the team contact and translation coordinator, thus having a few extra rights and responsibilities.
It is very important that translations are reviewed by a team, rather than a single person. Usually, a translator makes several errors of different nature that are easily spotted by people who have not participated in the translation of the article under question. The team leader has to make sure that prospective translations are reviewed, that they do not contain obvious errors and/or confusing expressions and that they match the spirit and intention of the original essay. However, many teams tend to suffer from a specific problem: team members rely on the leader to make these extensive reviews. That is fine, as far as it goes, and the leader should always review translations before installing them in the repository — but it is nearly impossible (especially for a large team) to rely on a single person for such tasks. Team coordinators often do not manage to make such reviews in time, resulting in frustration among the team members and generally slowing the translation process.
A solution to this specific problem is to distribute the load among more people. For example: Member D makes a translation of foo.html and uploads foo.bg.html in the translation's project repository at Savannah, marking the relevant task as “Ready for Test” (of course, the equivalent is sending a message with the attached translation to the team's mailing list, or similar). Then Member A, B and C (or only A and B if C is currently busy) review it independently and post comments/suggestions/errors in the bug tracker. Discussion goes on between them and D, problems are rectified and finally the leader (who may happen to be one of A, B, C, D) makes a final review. It is easier to make the final review when most of the issues are already fixed in previous revisions. Finally, the translation is published. The result is better quality of the translation (since more people looked at it) and the whole burden does not fall on the shoulders of the leader. You can also set up an internal formal rule: If a member makes a translation, he has to review another one (or two) as well.
Savannah
Every translation team should have a project in Savannah. For historical reasons those team names may vary a lot (e.g. spanish, www-bg, elwebtrans, etc.) Plus, there are some teams that use their own resources outside from Savannah; althought there's no obligation to use Savannah for team work, the need for a Savannah project for each language is obvious: it's a standard way to find information for translation teams and their contacts.
Those teams that are using Savannah, have a broad variety of tools at hand: team membership management, documents, trackers (bugs, tasks and support), alerts, CVS, home pages, mailing lists, etc. How each uses these resources it's up to the team itself.
Mailing lists
Mailing lists usually are linked to existing Savannah projects, but the software used to manage them (Mailman) isn't part of Savannah, which means that there are lists that aren't linked to any specific project, though may be related to some.
Aliases
On the other side, people with an account in GNU servers usually can update existing team aliases (e.g. web-translators-fr). However, this isn't recommended unless you know exactly what to do. Web translation managers have more experience on this and will take care of updating aliases at leader's request.
Team Leaders
People in charge of a translation team are team leaders and Savannah project admins. Usually, they're the only people from their team with write CVS access to the GNU website, and are listed as team contacts in translations README. Please, see also how to coordinate a translation team.
Web Translation Managers
Translation managers are those people coordinating translation coordinators (team leaders) and dealing with all sort of requests or issues related to GNU website translation, while trying to improve the translation procedures and coodinating with GNU webmasters, too.
Request Tracker (RT)
Request Tracker is a ticketing system that helps managing translation requests and issues to translation managers. It's the successor of former web-trans mailing list and was setup more or less like its brother queue webmasters primarily to deal with the huge amount of spam that web-trans was receiving. Sometimes, tickets are moved from other RT queues to web-translators and occasionally tickets from web-translators are moved into other queues.
There's the web-translators-staff group in RT that lists RT users with right in web-translators queue, web-translators-admin group for people in RT that can change web-translators config. Finally, there's a custom field specific to web-translators queue that helps tagging which language each ticket is related to. This custom field can only be managed by people in web-translators-admin group, but anyone in group web-translators-staff can use it to tag tickets.
Savannah
- www
- trans-coord
- specific translation team projects
- Savannah administration
Mailing Lists
There are a few mailing lists that every translation manager should be subscribed to:
- www-discuss
- www-commits (admin)
- trans-coord-discuss (member+admin)
- trans-coord-news (admin)
Some of them, will need that some translation managers become their admins too (as noted above).
Aliases
Translation managers should know how to update, create or remove aliases from GNU servers per request of translation team leaders. An account in GNU servers is a prerequisite.