On 8/7/07, Dan Scott <[EMAIL PROTECTED]> wrote: > On 04/08/07, Dan Scott <[EMAIL PROTECTED]> wrote: > > On 01/08/07, Mike Rylander <[EMAIL PROTECTED]> wrote: > > > On 7/30/07, Dan Scott <[EMAIL PROTECTED]> wrote: > > > > On 27/07/07, Dan Scott <[EMAIL PROTECTED]> wrote: > > > > > On 27/07/07, Dan Scott <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://esilibrary.com/
