UI i18N message strings are not standardized

Description

The OpenLMIS-UI message keys need to get cleaned up so they are similar to other openlmis service keys.

Acceptance Criteria

  • Refactor all translation strings to meet the following criteria

    • pre-fixed by module name where string is used (ie `openlmisPagination.next` or `reqisitionInitialize.view`

    • Follows message key guidance from OpenLMIS coding conventions (note camelCase)

    • Use location suffixes if the same module has multiple similar strings in different locations that would require different punctuation rules (ie `label` or `title` as in `requistionView.search.title` and `requisitionView.search.label`)

  • Each module/folder has its own translation message keys, and message keys are never reused outside of their own files

Sample UI file structure:

  • src

    • openlmis-pagination

      • messages_en.json

    • requisition-view

      • messages_en.json

Attachments

4

Activity

Show:
Paulina Borowa
April 19, 2017 at 9:51 AM

Seems to be ok now.

Paulina Borowa
April 18, 2017 at 3:55 PM
(edited)

Last two things I hope so:

  1. button on convert to order view:

  2. button 'Search' on view orders:

Paulina Borowa
April 18, 2017 at 12:52 PM
(edited)

When I change state for requisition I get wrong message which looks like this:


The table also has an error but I am not sure if it is related to this ticked, instead of 'Date submitted' there is 'requisitionApproval.date.submitted'

Nick Reid
March 7, 2017 at 11:40 PM

This is ready for work // There will be a second ticket about changing from JSON files to `.po` files like the services (and to make message files seem different) – this ticket needs to be vetted first, so you can hold off on this ticket or get the renaming work and file splitting work done

Nick Reid
March 5, 2017 at 9:10 PM

Since you have the most experience working with these strings... I thought I'd get some feedback about how these translation strings should work...

Important points for feedback:

  • Message strings are defined for each Angular module/folder — they should never be reused outside of those locations — goal is to allow implementers to customize specific strings where needed (and keep file size down)

  • 'label' and 'button' suffixes only used if there is string duplication

Question that I'm really tempted to add to this work: Format files as java property files, NOT json files (we can use a build process to quickly parse these) — and I think we should do this now and refactor these strings once as part of 3.0.1

CC

Done
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Labels

Story Points

Original estimate

Time tracking

4d 4h logged

Components

Sprint

None

Fix versions

Priority

Time Assistant

Created January 5, 2017 at 9:13 PM
Updated April 26, 2017 at 9:10 AM
Resolved April 19, 2017 at 9:50 AM