[OPEN-ILS-DEV] Re: PATCH: Move strings from xul/chrome/content/main/*.xul into lang.dtd

[Dan Scott]

On 04/08/07, Dan Scott <denials at gmail.com> wrote:
> On 01/08/07, Mike Rylander <mrylander at gmail.com> wrote:
> > On 7/30/07, Dan Scott <denials at gmail.com> wrote:
> > > On 27/07/07, Dan Scott <denials at gmail.com> wrote:
> > > > On 27/07/07, Dan Scott <denials at gmail.com> wrote:
> > > > > Hi:
> > > > >
> > > > > Taking this one step at a time, I'll move the remaining hard-coded
> > > > > strings from main/*.xul into lang.dtd.
> > >
> > > Here's an updated patch that also moves the accesskey attribute values
> > > from chrome/content/main/*.xul into entities defined in lang.dtd. In
> > > case anyone is interested, I'm doing this because the mnemonics for
> > > items in one language won't necessarily make sense in another language
> > > (for example, "Cancel" in French is translated "Annuler", so a "C"
> > > accesskey wouldn't make sense in French).
> >
> > Applied for about 3 minutes, then reverted ... sorry :(
> >
> > Short version: The staff client uses two techniques for building
> > interfaces: chrome:// (local, client-side content) and http://.
> > Mozilla chrome has its own i18n mechanisms, but AFAIK we're not making
> > use of them yet.  The remote (http) stuff will use mod_xmlent, just
> > like the OPAC.  This patch was built using the mod_xmlent mechanism,
> > but the files altered live in local chrome ...
>
> Resubmitting the patch, with one change to an incorrect entity that
> caused the XML to not parse properly. Combine this patch with my
> previous patch for correcting the conversion of entities to JavaScript
> property files, and you have yourself an internationalized main frame
> + main menu. I have tested this successfully on my local Evergreen
> instance with OpenSRF 0.9 and ILS trunk.
>
> 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.

Thanks for applying the patch, Mike. Unfortunately, a quick test of
the results of the frenzy of i18n patch-merging shows that
main_i18n.txt v2 was applied, not main_i18n.txt v3. I should have
named them as such when I attached them throughout this thread to
avoid any confusion... sorry about that. I'll try to do better in the
future.

Attached is the diff between main_i18n.txt v2 and main_i18n.txt v3 - a
one line fix that enables the menu to actually appear on the main
frame. Small, but rather critical :)

-- 
Dan Scott
Laurentian University
-------------- next part --------------
A non-text attachment was scrubbed...
Name: replace_barcode.patch
Type: application/octet-stream
Size: 1227 bytes
Desc: not available
Url : http://list.georgialibraries.org/pipermail/open-ils-dev/attachments/20070807/5abaac37/replace_barcode.obj