Versions Compared

Old Version 4

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 5

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Investigate auto-converting both *.properties files and *.xml files to a single standard format (*.pot or similar) for translators. (idea from helix84)
  • 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)

Path to Submit a new Translation is Frustrating

...

  • Investigate creating a new i18n submission workflow via GitHub? Maybe have a separate i18n GitHub repo, which we can provide translators with more direct access to or similar. During DSpace releases we can either pull updates from this repo, or even potentially release directly from it. (Tim Donohue, original idea from helix84)

...

  • 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)
  • 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. (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)

What are other open source platforms using for i18n?

...