As I mentioned elsewhere, we have no windows frontend maintainer so feature development specific to windows does not currently happen.
The win port uses windows 2000 compatible GDI calls and I imagine this is the cause for GIF flickering, SVG not rendering and truetype fonts not being used.
The core browser functionality does support javascript, however there are thousands of DOM bindings and our progress in implementing them all is slow.
We are a very small team and rely on maintainers to actively look after a frontend. For example Chris does a brilliant job keeping the Amiga frontend in shape and I keep GTK going. Other frontends like Windows, RISC OS and Atari lack a maintainer altogether and are kept going purely through inertia.
Unfortunately the Mac OS X frontend became unmaintained some time ago and eventually stopped working altogether which resulted in its removal from the master branch and hence releases.
I did not use it because it was an unverified python script with a bunch of dependencies, as a rule I generally do not like executing untrusted code without at least a basic review.
As you mentioned, the Perl script was 100 lines and was easier at that moment in time to integrate than to review the python.
Of course once the python client has been reviewed perhaps it would be a more general solution.
Transifex have extended the format and allow resources to be UTF-8 encoded (see http://help.transifex.com/features/formats.html#java-propert... ) however the importer does not correctly cope with single quote characters, backslash n (newline) and several other characters being encoded when they ought to be (as per the document you referenced which I also used to begin with ;-)
The gettext PO file format does indeed provide many other features, I do not disagree, but there does seem to be an over reliance on it within the platforms I looked at.
The format does have some pretty major drawbacks too, like the msgid can become "fuzzy" which leads to a differing set of issues related to the unique keying between translations.
It also tends to lead to developers English (C locale if you like) being selected as the default language and it turns out developers like myself are sloppy and sometimes produce barely parsable messages.
Your remaining points are really valuable to someone inexperience in the field, like myself, so thanks for pointing those out.
It is interesting you call out cultural issues, did you have any specific examples?
> The format does have some pretty major drawbacks too, like the msgid can become "fuzzy" which leads to a differing set of issues related to the unique keying between translations.
I am not sure how much of an issue this is in practice. The main problem of the PO format AFAICT is that it is quite outdated. For instance, it has no support for genders and you cannot "mix" plural rules within a phrase.
> It is interesting you call out cultural issues, did you have any specific examples?
The wikipedia entry on l10n[1] has some examples.
The process of localization is not merely about translating some strings, but adapting them to a specific language and culture, which is the hardest part. For instance, your home page is one of the most important pages in your app and is geared to make as many people as possible sign up. Do you think a simple translation would have the same effect on British, French, Arabs, Japanese etc people?
Cultural issues include whether or not it is appropriate to bring up a particular point in the first place, visual design (eg. cultural norms for button or multi-point statement/list ordering, spacing, typeface size, etc.), special overtones implied by the use of certain words or combinations thereof, in some cases whether the use of text or icons is appropriate for a given translation, whether certain phrases or features should be 'off limits' (eg. due to cultural taboos, eg. impossible to configure a system in such a way that is disrespectful to one or more religious deities or real world monarchs), etc.
I think the Boston Viridis falls into the "commercial blade server" category and as suggested in the conclusion is how it should be done if you were not using existing dev boards.
Is that an invite to show me round Cambridge MakeSpace? ;-) I was thinking about the open evening on tuesday but it is very inconvenient.
The browser is a little limited in its javascript support (and hence rendering of a lot of modern sites) but it should not crash in general operation.