wiki:I18nBounty

Bounty for Internationalization

Registration of interest due by: 13 June 2005
Bounty Discussion

Bounties

A bounty is similar to a fixed price contract, but less formal and more in tune with Open Source. The hope is the bounty is a task the developer believes in and would like to do anyway and the money paid is just an extra incentive. Acceptance of any work done into an Open Source project should always be determined by its quality and if it makes the project better, not if meets some legalistic requirements. For this reason the criteria for granting a bounty depends on the satisfaction of the project owners.

Bounty Contest Rules

Process for Bounties (adopted from Mark Shuttleworth and Gnome Bounties)

  1. Contact the eXe team (mailto:exe@…) and establish which project you are interested in and your credentials.
  1. A forum thread will be created for the bounty, please add a comment to this issue. This is to encourage involvement from the community and if multiple people want to work on the same task, they can more easily find each other and collaborate.
  1. We will advise if we want you to work on the bounty and give a time frame within which we expect it to be completed.
  1. All submissions must be open source, without any known intellectual property

encumbrances that might stop the submission from being distributed as free software.

  1. Your patch has to work, and it has to work nicely.

"I just got it working," or "it works most of the time," or "it works but the UI is just a placeholder," or "what — I have to add UI?" don't cut it.

  1. Bounties that are completed by submitting a patch and got accepted should be claimed with in a month of time.
  1. Once the code is accepted, to the satisfaction of people judging panel, we pay the agreed bounty.
  1. Our decision is final. We're not out to mess anyone around, and you have the whole internet to complain to if you don't like it.

Background

The objective for this bounty is to complete the gettext portion of Internationalization of eXe.

Internationalization refers to the operation by which a program is made aware of and able to support multiple languages and cultures. Localization is the operation by which, in a program already internationalized, one gives the program all needed information so that it can adapt itself to handle its input and output in a fashion which is correct for some native language and cultural habits.

To support Internationalization (I18n) and Localization (l10n) of eXe we are using the standard GNU gettext library. Experiments have shown gettext works on Linux and Windows and makes it easy to both extract strings from the source code for translation and look up the appropriate message for a given locale.

We think it's important the user can select a different locale than that set in the operating system.

Current status

Throughout our code we have marked human readable strings by wrapping them in a function call, e.g. _("Feedback"). This means they are already available to be hooked into the gettext system. Our experiment in using gettext can be found in prototype/packtest directory of the eXe source code. This can be downloaded using [:SourceControl: Subversion] from http://exe.cfdl.auckland.ac.nz/svn/exe/trunk, or as a tarball using WebSVN. The updatePo.sh and makemo.sh scripts should be of particular interest.

Although everything worked fine with the prototype, with eXe we ran into a problem with our larger MO files being reported as curropt on Windows. We were using tools from CygWin? there.

What is needed

Building the gettext language files

  • Tools and instructions needed for creating and maintaining gettext PO and MO files on Windows, Linux and MacOSX.
    • As far as possible the process should be automated
  • We'll have to add the MO files to the install, but we can do that ourselves?
  • An English and a non-English locale for testing
    • The non-English locale doesn't have to be a proper translation and could consist of just gibberish. It purpose is so we can see what strings are being replaced. (Klingon would be fine too)

eXe configuration

  • Add the current locale as a setting in exe.conf and config.py
  • The default should be the locale reported by the operating system

eXe GUI for changing configuration

  • A preferences dialog which displays the available locales and allows the user to select one
    • Selecting a new language will cause all elements of the GUI to update so that the new language is shown
    • Be aware we'll be adding other preferences to this dialog, so it'd probably be best if the locale option doesn't take up too much room
  • The locale set should be "remembered" by eXe
    • i.e. config.py will need to save itself back to exe.conf when changes are made

Identification of "holes"

Identify holes where more work is still required to Internationalize eXe. For example: English strings in the code which haven't been marked, in the nevow templates, in the Javascript, in the CSS, any images which include text.

Quality Expectations

  • Everything has been tested - on Windows, Linux and MacOSX
  • Code submitted conforms to our CodingStandards
  • Unittest are updated and/or provided
  • Documentation is clear and easy to follow

Suggested references

For the eXe team...

Estimation of Scope

  • 1.4.1, 1.4.2, and 1.4.4 should be pretty straight foward for someone who has done this before.
  • 1.4.3 is a bit more tricky, they'd have to understand how our user interface code works which could be changing underneath them, but I'm sure Mathew could help them there :)
  • Suggested bounty : $1200 NZD

Other comments

  • should we give the bounty hunter write access to our source code, or accept patches or put them on a branch and try and merge it later?

Definately Accept Patches, not write access! (MS)

  • add anything you like here