[OPEN-ILS-DEV] PATCH: Introduce XUL string bundles for Javascript
i18n
Dan Scott
denials at gmail.com
Mon Aug 6 22:53:44 EDT 2007
As documented at
http://developer.mozilla.org/en/docs/XUL_Tutorial:Property_Files ,
string bundles are the normal method for holding translatable text
from Javascript files in XULRunner applications. The staff client
currently does not use string bundles; it currently uses a mix of
hardcoded strings, with reliance on some of the strings that are
converted from lang.dtd into the massive hash that is lang.js.
This patch hopes to start changing that, by introducing string bundles
for a few small parts of the staff client -- hopefully paving the way
for conversion of more of the client to stringbundles and i18n glory.
1) We create one .properties file per chrome/content/ subdirectory
that we're converting to string bundles, plus a common.properties file
for common strings like error messages. In this patch, I address the
chrome/content/admin/ and chrome/content/cat/ directories; therefore,
I add:
* Open-ILS/xul/staff_client/chrome/locale/en-US/admin.properties
* Open-ILS/xul/staff_client/chrome/locale/en-US/cat.properties
* Open-ILS/xul/staff_client/chrome/locale/en-US/common.properties
2) Note that the files are being added to a directory that does not
currently exist in the Subversion repository. It doesn't make sense to
serve the properties files remotely from the web/locale/en-US/
directory, as their real home is the chrome. So that's where I've
stuck them. Accordingly, the xul/staff_client/Makefile has been
modified to no longer make this directory.
3) chrome/content/cat/opac.xul has been converted to a fully i18n-ized
file, by adding XML entities to web/opac/locale/en-US/lang.dtd and
converting hardcoded strings in the Javascript to stringbundle calls
that pull in the properties defined in cat.properties and
common.properties.
4) chrome/content/admin/survey* have also been given the entity &
stringbundle treatment.
I have tested the opac and survey screens in the client and nothing
seems to be going wrong, so I'm taking that as a good sign :)
Jason -- If you have any questions wading through the set of patches
I've fired in your direction, feel free to ask!
Developer's Certificate of Origin 1.1
Developer's Certificate of Origin 1.1 By making a contribution to this
project, I certify that:
(a) The contribution was created in whole or in part by me and I have
the right to submit it under the open source license indicated in the
file; or
(b) The contribution is based upon previous work that, to the best of
my knowledge, is covered under an appropriate open source license and
I have the right under that license to submit that work with
modifications, whether created in whole or in part by me, under the
same open source license (unless I am permitted to submit under a
different license), as indicated in the file; or
(c) The contribution was provided directly to me by some other person
who certified (a), (b) or (c) and I have not modified it; and
(d) In the case of each of (a), (b), or (c), I understand and agree
that this project and the contribution are public and that a record of
the contribution (including all personal information I submit with it,
including my sign-off) is maintained indefinitely and may be
redistributed consistent with this project or the open source license
indicated in the file.
--
Dan Scott
Laurentian University
-------------- next part --------------
A non-text attachment was scrubbed...
Name: props.patch
Type: application/octet-stream
Size: 19045 bytes
Desc: not available
Url : http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20070806/264cbf78/props-0001.obj
More information about the Open-ils-dev
mailing list