evergreen-admin:customizations:i18n
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
evergreen-admin:customizations:i18n [2008/09/17 15:01] – Replaced "the manifest" (a generic term) with ''chrome.manifest'' (a reference to a specific file) sylvar | evergreen-admin:customizations:i18n [2018/06/05 11:06] – adding another prereq sandbergja | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ======Internationalization (I18N), Localization (L10N), and Globalization (G11N)====== | ||
+ | Evergreen started as a project for the state of Georgia. Fortunately, | ||
+ | |||
+ | =====Localization===== | ||
+ | |||
+ | ====Build environment==== | ||
+ | |||
+ | The translatable strings from the i18n files are being converted to GNU gettext (POT and PO) format for ease of translation. The corresponding tools for converting the files to and from the gettext format and their native format live in the build/i18n/ directory. They require a few supplemental tools over and above the normal Evergreen requirements. | ||
+ | ===Prerequisites=== | ||
+ | On Debian, install the translation build tools:< | ||
+ | apt-get install translate-toolkit python-dev python-levenshtein python-polib python-setuptools python-simplejson python-lxml | ||
+ | </ | ||
+ | |||
+ | For Ubuntu, you may also need '' | ||
+ | |||
+ | ===Creating or updating a set of PO files for translation=== | ||
+ | To create or update a set of PO files for a particular locale from the translatable files in your current Evergreen source directory:< | ||
+ | # Change into the i18n directory | ||
+ | cd build/i18n | ||
+ | # THIS MUST BE DONE ALSO | ||
+ | mkdir locale | ||
+ | # Update the en-US POT files | ||
+ | make newpot | ||
+ | # Create or update the PO files for the locale ' | ||
+ | make LOCALE=fr-CA updatepo</ | ||
+ | |||
+ | ===Creating translated project files from translated PO files=== | ||
+ | To create the translated project files for a locale from a set of translated PO files in the '' | ||
+ | # Create new project files for the locale ' | ||
+ | make LOCALE=fr-CA install</ | ||
+ | This will automatically update the PO files with the latest definitions from the en-US source POT files, then generate the full set of project files for the requested locale. Any strings that have not been translated, or that are marked as " | ||
+ | |||
+ | **NOTE** If you have trouble installing your translated .po-files, make sure you are installing your files in valid gettext-standard PO-format. Things to look for include (but not limited to): | ||
+ | * BOM BOM! Gettext tools do not support BOM (http:// | ||
+ | * Runaway newlines. Some translators like to end their translations to a newline. On each row, msgid and msgstr definitions must have a starting and ending double quote | ||
+ | |||
+ | ===Inserting the strings into the database=== | ||
+ | A number of initial " | ||
+ | <code bash> | ||
+ | # Install the fr-CA strings in the Evergreen database: | ||
+ | # * hostname ' | ||
+ | # * username ' | ||
+ | psql -h localhost -U evergreen -f Open-ILS/ | ||
+ | |||
+ | **NOTE** This does not copy the correct files into / | ||
+ | |||
+ | **NOTE** If you fail to INSERT your 950.data.seed-values-< | ||
+ | <code sql> | ||
+ | INSERT INTO config.i18n_locale VALUES (' | ||
+ | </ | ||
+ | |||
+ | ===Localizing the TPAC=== | ||
+ | To make your localization visible in the TPAC, you should follow these instructions: | ||
+ | http:// | ||
+ | =====Technical details behind localization===== | ||
+ | The technical details of how we handle localization in Evergreen - staff client, catalogue, and OpenSRF - have been moved [[backend-devel: | ||
+ | |||
+ | =====Other internationalization features===== | ||
+ | We will want to explore how the catalog handles collation, diacritics, etc. I wrote a small blog post about these features at http:// | ||
+ | |||
+ | ====Collation==== | ||
+ | The collating sequence for the entire PostgreSQL database cluster is determined by the initial '' | ||
+ | |||
+ | Mike has this crazy idea where, if you search for works written or performed in a specific language in advanced search, the collating sequence should dynamically switch to sort the results according to the rules for that particular language. If he can get that to work -- awesome! | ||
+ | |||
+ | See [[http:// | ||
+ | |||
+ | |||
+ | ====Spell checking==== | ||
+ | Evergreen uses '' | ||
+ | |||
+ | ====Diacritics in search==== | ||
+ | Search currently ignores diacritics (e == é == è) as diacritics are removed during indexing normalization. | ||
+ | |||
+ | ====Number, date, time, currency formatting==== | ||
+ | Locale-specific data is currently formatted according to en-US conventions. We're looking at using [[http:// | ||
+ | |||
+ | =====Globalization (G11N)===== | ||
+ | We need to be able to reflect the requirements of different countries. Consider this a stub section that will eventually be replaced by a HOWTO document explaining, for example, how to alter the patron templates for states and zip codes to provinces and postal codes. | ||
+ | |||
+ | A simple approach is to modify the labels in the DTD for the staff client and the OPAC ('' | ||
+ | $ grep -i zip *.dtd | ||
+ | |||
+ | lang.dtd:< | ||
+ | lang.dtd:< | ||
+ | lang.dtd:< | ||
+ | opac.dtd:< | ||
+ | </ | ||
+ | |||
+ | There are other implications in the client code (for example, the JavaScript includes regular expressions that check the contents of a field and expect it to be a five-digit ZIP code). But it's a start. | ||
+ | |||
+ | ====Conify interface g11n problems==== | ||
+ | Just keeping track as I take a first pass through these interfaces... | ||
+ | * Org unit interface: | ||
+ | * **Major**: Has inline JavaScript regexes for telephone number, zip code |
evergreen-admin/customizations/i18n.txt · Last modified: 2023/08/11 10:40 by sandbergja