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

[Mike Rylander]

On 8/7/07, Dan Scott <denials at gmail.com> wrote:
> 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 :)
>

Applied.  Versioning the patches is definitely a good idea.  Thanks, Dan.

-- 
Mike Rylander
Equinox Software, Inc
miker at esilibrary.com
http://esilibrary.com/