[OPEN-ILS-DEV] [open-ils-commits] r12510 - in trunk: Open-ILS/web/reports/xul build/i18n/po/en-US (miker)

[Dan Scott]

2009/3/13 Mike Rylander <mrylander at gmail.com>:
> On Fri, Mar 13, 2009 at 5:47 PM, Dan Scott <denials at gmail.com> wrote:
>> Note that you don't / shouldn't update POT files directly; instead,
>> you want to update the corresponding native en-US file (
>> Open-ILS/web/js/dojo/openils/reports/nls/en/us/reports.js in this
>> case).
>
> Unfortunately, no such file exists.  Firebug tells me that
> Open-ILS/web/js/dojo/openils/reports/nls/reports.js does, though, so
> I'll move my updates there and clear out the rest of the strings.

Ah, good catch. That's what I get for firing off a quick email at the
end of a long jet-lagged day. Sorry for leading you astray.

>> "make newpot" generates updated POT files and will overwrite
>> these changes based on the contents of reports.js. Similarly, just add
>> entity definitions directly to lang.dtd rather than lang.dtd.pot -- or
>> in this case hardcoding strings in the XUL -- heh :)
>
> I believe that at this point you're the only one that knows the "best
> practices" for all of the moving parts of i18n, so you'll need to bear
> with the me (or point me to the the docs I missed on your dojo-PO
> integration).

Docs, ah yes... the Dojo-PO piece was the last part I added during the
lead up to 1.4 and has suffered the ignominy of not yet having any
developer-oriented docs written about it, I'm afraid. My apologies!

The Dojo JavaScript property files are nice and simple - they're just
JSON hashes, where the key maps to a translation string, and you can
use variables in the string using ${0} ${1} notation.

>>
>> I suppose we could delete the POT files from SVN. I had checked them
>> in to make it relatively easy for someone to grab a copy for their own
>> translation purposes; but if it's going to cause confusion, I can turf
>> them.
>>
>
> It seems to have, yes.  If we leave them in place, what mechanism do
> you suggest for keeping them up to date?  We don't want translators
> translating from what amounts to the previous version's strings, I
> would think.

Well, given that the POT strings will likely be 9x% the same from
release to release, that's not so bad - and it was nice and easy to
point to the Trac instance for translators to download the POT files.
However, I have now removed them from the repository because the last
thing I want to do is slow down development.

One of the sites doing a translation had mentioned they were going to
host a Pootle instance for the Evergreen community, which would
simplify things significantly (provides a nice Web-based translation
interface and automatically generates reports on translation
completion percentages). That has not yet come to pass, though, so
perhaps I'll try running an instance on coffeecode.net.

-- 
Dan Scott
Laurentian University