On Thu, May 24, 2012 at 02:53:28PM +0000, Duimovich, George wrote: > > Hello Dan / Lebbeous, > > Regarding the GSOC proposal on Overhauling internationalization > support in Evergreen here: > > http://evergreen-ils.org/dokuwiki/doku.php?id=dev:summer_of_coding_ideas > > Are there any examples in the Template::Toolkit code for 2.2+ that > demonstrate any of the i18n advantages you folks had in mind over the > current approach (for either Staff Client or TPAC)? > > How much 'heavy lifting' would be required to revisit and re-code a > sample approach for best practices going forward? Or is there already > a pretty clear approach that would have to be taken for any TT-based > interface etc.?
Hi George: Actually, I think the TPAC currently demonstrates best practices when it comes to i18n support in Evergreen - at least as far as text goes. I think it was Bill Erickson who did the bulk of the work to support things like pluralization forms. The TPAC presentation we did at EGConf 2013 (http://goo.gl/qyEqV) has some examples of using the l() wrapper for marking translated text. There is also a note in the older TPAC tutorial I wrote that got pulled into the docs at http://docs.evergreen-ils.org/2.2/_changing_some_text_in_the_tpac.html about localizing text. There is also some info about providing your own customized or translated strings at http://evergreen-ils.org/dokuwiki/doku.php?id=dev:opac:template-toolkit Someday we'll pull all of that back into the docs in one authoritative place :) There's definitely more work that needs to be done to support globalization, in terms of currency display, date / time formats, etc, but as far as text goes in the TPAC, we're in good shape. (Well... I hadn't thought about right-to-left text yet; we probably need a domain expert to tackle that support if we want to go there. The good news is that TPAC should be infinitely easier to work with to provide that support...) So that's TPAC. The same i18n support is available for anything built on Template::Toolkit, so acquisitions (which currently has lots of hardcoded strings), bookings (which currently uses Dojo's i18n approach to completely decouple text from the template), serials (hardcoded strings), etc could all benefit from an i18n overhaul. Dan