Page History
...
- GetText (GetText-Commons available for Java)
- Pootle
- Transifex
- Launchpad
- http://translationproject.org
- http://en.wikipedia.org/wiki/Computer_Assisted_Translation
- http://omegat.org/en/omegat.html
- https://en.wikipedia.org/wiki/Translation_Memory_eXchange standard for exchange of translation strings.
Brainstorming potential solutions:
...
- Perhaps we need to better communicate or "standardize" the location of these i18n files across all modules? Currently i18n files are in different locations (subfolders) based on whether you are looking at the dspace-api, dspace-xmlui-webapp, or a newer module like 'dspace-discovery-xmlui-api'. There is seemingly no "standard" location to find these messages files. (Tim Donohue)unmigrated-wiki-markup
- In the past, I vaguely recall ideas around having a generic place to "drop-in" localized i18n files. For example, if there was a \ [dspace\]/config/i18n/ folder, you could potentially "drop-in" your own custom version of various messages files for each module. Although this may not help translators, it could be useful for users. Imagine if you could just drop-in all your customized messages files (for XMLUI, API, Discovery) into a single location and DSpace would just use those -- – it would mean no more searching for the proper "drop-in" folder for each module. ([~tdonohue]Tim Donohue)
Not all Text is Easily Translatable
...
- Obviously, we need to investigate ways to bring more of that text either into translatable metadata fields (like Item metadata) in the DB, or migrate them to *.properties files (perhaps similar to how "item-submission.xml" file can references keys in messages files for <heading> text). This may need to be something we slowly improve over several releases. (Tim Donohue)
- Storing and transporting strings in .xml files rather than *.properties files hugely reduces the changes that tools incorrectly guess the character encoding.
What are other open source platforms using for i18n?
...
Overview
Content Tools