po vs. properties, round 2

["mitcho (Michael 芳貴 Erlewine)"]

Hi all,

(cc: l10n-drivers, whose opinion I would love to get as well)

As some of you know, Lech as been doing a fantastic job getting our
about: pages and various UI strings localizable using the regular
Mozilla style of DTD's (for XHTML/XUL) and properties (for JS). Before
we make a push for localizers to do their magic, I'd like to propose
the use of po files over properties for the JS strings. If we simply
use the DTD's and properties that Lech graciously set up, we'd have a
Ubiquity localization ecosystem with three different file formats: po,
properties, and DTD.

Based on our previous discussion of po vs. properties, I believe
putting everything in po is the way to go. po is a de facto standard
with numerous tools available, is used by a variety of open source
projects and is widely used, and it has the advantage of being a
multilingual format.

I'll look forward to comments and hopefully we can decide on a
direction relatively soon, then we can encourage localizers to take a
look at the newly localizable content. :)

mitcho

--
mitcho (Michael 芳貴 Erlewine)
mit...@mitcho.com
http://mitcho.com/
linguist, coder, teacher

[Blair McBride]

Just to clarify, do you mean replacing the use of .properties AND .dtd
with .po, or just .properties ?

- Blair

["mitcho (Michael 芳貴 Erlewine)"]

Just the properties component.

So po (JS) + DTD (for XHTML/XUL), rather than po+properties+DTD.

m

[Lech]

Hey everyone,

For some better context to this discussion, as mitcho mentioned: this
would be primarily for only translations relating to scripts in the
Ubiquity core & for strings found within their respective JS files
(for the addon itself) which I posed in chat as I started digging down
into the core to prepare for some string collection. Normally a
properties file would be used for this operation which would be
handled by native Firefox locale handlers which would perform the
transformations without having to add much code.

We had a long discussion covering all strengths, and relevance of each
format vs how localizations are set up at the moment and how Firefox
doesn't currently support .po files along with an edge case and other
related concerns. But with that in mind it still creates a fork
between how command translations and ubiquity translations found in
the core are handled and how in the end users may want to set (or
unset) things.

Currently command translations are being handled by a well-coded .po
file parser which I personally don't want to trash because... well,
mitcho has obviously put a lot of work into it and it's doing a good
job so there's no good reason to replace it just yet. But the question
I proposed to the group which caused us to ask the following questions
is: How can we best attack translations on the Ubiquity core and keep
things relatively sane and organized? And would managing 3 different
types of unique translations across two separate and unrelated
locations (one for commands and one for core) be too much?

So the attack plan here goes a little deep since as it stands we're
serving up 2 different kinds of localizations in various formats and
trying to decide early on whether to favor portable objects or
properties in regard to having native translations for the about: UI
the related tools as well as commands and thoughts on how to possibly
merge and maintain it all. And while mitcho ensures me the .po file
parser is up to the task, I am currently more familiar with working on
DTDs and Properties files at the moment. I also have some reservations
on if this might impact performance in any way, but that's a big if
and a possible edge case.

So to summarize, DTD files are not being questioned here as they're
already reliable and known to work for our purposes in getting
translations of text on the about page. They're not 100% done yet, so
you can look but I would suggest waiting until we've fully baked them
before going forward with making translations. But if we switch from
properties to portable object files for JS translations, mitcho
ensures me we can duplicate how properties files behave in regard to
working with the DTD files within the core and on about: pages.

I have no reasons to doubt him or you guys, but I personally prefer
properties files for this job as much as mitcho pushes me to use
portable object files. Consider me a little bit stubborn :) However,
it's up for discussion and I would love to get some insight on what
everyone has to say on the topic and perhaps offer some ideas on how
to make managing translations easy for both us and you.

Thanks :)
-L

--
-L

[marsf]

There is no probrems to use 3 (or I think 2) different ways to
localize.
Lech's great working part is for native content strings of Ubiquity
like other add-ons, so I think it should be used regular Mozilla style
method. If it has separated the parser related part and the native
content part, more localizers can contribute only for native content
part without its locale's parser is ready.

In addition, we can throw them (dtd and properties) to BabelZilla and
will get help from them.
http://www.babelzilla.org/

--
marsf

On 8月2日, 午前7:12, "mitcho (Michael 芳貴 Erlewine)" <mit...@mitcho.com>
wrote:

["mitcho (Michael 芳貴 Erlewine)"]

Hi all,

I apologize for the late reply, but following a call with the l10n-
drivers, we've decided to keep the properties + DTD's for the core add-
on UI and about + settings pages, while the command localizations are
in po.

The drivers expressed that they would not be worried by having "too
many" file formats and if anything, these two aspects of Ubiquity
localization may expose Ubiquity localization to more community members.

Unless there is opposition, I hope to submit the extension to
Babelzilla (http://babelzilla.org) after the 0.5.2 release tomorrow.
Babelzilla was suggested for use by both marsf and the drivers.

Thanks again to Lech for his fantastic work on making the about pages
localizable! Bravo!

mitcho