Versions Compared

Old Version 9

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version Current

changes.mady.by.user stuart yeates

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

Brainstorming potential solutions:

  • Investigate auto-converting both *.properties files and *.xml files to a single standard format (*.pot or similar) for translators. (idea from helix84)
    • .properties and .xml should be treated separately, as they are different in content not only in format (Christian Völker)
    • .properties has another issue: it's a mix of JSPUI text and text used by dspace-api, they might need to be separated out (Mark Wood)
  • OR investigate standardizing DSpace i18n on a single format, likely *.properties. Though this may mean writing our own i18NTranslator class for Cocoon (as I don't believe the default one supports *.properties, but I could be mistaken). (Tim Donohue)

...

  • 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)
  • Wiki MarkupIn 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

...

  • email templates (under 'config/email')
  • dspace.cfg ('dspace.name')
  • Other configs under 'config/modules/' (curate.cfg, etc.)
  • input_forms.xml
  • Community & Collection descriptions (this is a result of Communities & Collections not having full Metadata support, like Items) See also DS-1134
  • Certain XMLUI Value pairs (Three pairs of button labels: "Add" and "Remove Selected") (See: DS-1159)

Brainstorming potential solutions:

  • 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?

Please add to this list!