Difference between revisions of "JSON Resource Bundles"

From Lingoport Wiki
Jump to: navigation, search
(Arrays are not allowed in the context of JSON files as resource bundles)
 
(27 intermediate revisions by 4 users not shown)
Line 4: Line 4:
 
JSON files are increasingly used with JavaScript as a means to capture strings to be translated.
 
JSON files are increasingly used with JavaScript as a means to capture strings to be translated.
   
  +
== Example of LRM Supported JSON Files ==
== JSON File Naming ==
 
  +
In order to detect and import changes, LRM 2.1 requires JSON files to also adhere to the following standards.
 
  +
=== Typical ===
The json files must follow this naming convention: '''filename_<locale>.json''' or '''filename_<locale>_<country>.json'''. For example,
 
  +
This file, named for instance ''errors_en.json'', looks similar to a .properties file, with a key/value pair on each line. This is the most common and simple file to handle:
  +
<pre>
  +
{
  +
"title": "Woops!",
  +
"message": "Something went wrong. Try again later."
  +
}
  +
</pre>
  +
  +
=== Typical with Keys for Comments===
  +
This file, named for instance ''resources_en.json'', looks similar to a .properties file, with a key/value pair on each line. The first line has a key which start with an underscore, indicating a description for the key just after it. The text for "_description_groupAccessOpen" will not be translated:
  +
<pre>
  +
{
  +
"_description_groupAccessOpen", "To help users with the Open in the top window",
  +
"groupAccessOpen": "Open",
  +
"groupAccessInvitationOnly": "Invitation Only",
  +
"groupAccessRequestToJoin": "Request To Join",
  +
"all_volunteers" : "All Volunteers"
  +
}
  +
</pre>
  +
  +
=== Objects ===
  +
The keys must be unique within a file. Sometimes, objects allow for an organization within the files which matches the developers' code.
  +
<pre>
  +
{
  +
"the_cat": "The Cat",
  +
"dogs": {
  +
"pitbull": "A pitbull",
  +
"collie": "A collie",
  +
"small_dogs": {
  +
"poodle": "A teacup poodle"
  +
}
  +
}
  +
}
  +
</pre>
  +
  +
  +
== JSON File Structure ==
  +
  +
As with all resource files, LRM requires JSON files to adhere to specific standards in naming and directory structure in order to detect and import changes.
  +
  +
The locale of the target files must be made explicit through either a pattern of file names or a pattern of directory names. Please use the same pattern consistently - as only one pattern is supported per file extension per project.
  +
  +
This is described in depth at [[On_Boarding_an_LRM_Project#Build]]
  +
  +
A few examples for reference:
  +
  +
=== Locale Defined in File Name ===
 
*'''resources_en.json''' or resources_en_US.json,
 
*'''resources_en.json''' or resources_en_US.json,
* '''resources_fr.json''' or resources_fr_FR.json, etc.
+
*'''resources_fr.json''' or resources_fr_FR.json, etc.
   
  +
With multiple directories such as:
We strongly recommend file names should be unique, even if they are in different directories. LRM sends unique file names per prep kits. For example, if you have two JSON files under locales/ and under module1/locales, you could name them:
 
 
* locales/common_resources_en.json
 
* locales/common_resources_en.json
 
* modules1/locales/module1_messages_en.json
 
* modules1/locales/module1_messages_en.json
  +
  +
=== Locale Defined in Directory Name ===
  +
*'''en/resources.json''', '''fr_FR/resources.json''', '''zh_TW_HANS/resources.json''',
  +
OR
  +
*'''modulename_en/resources.json''', '''modulename_fr_FR/resources.json''', '''modulename_zh_TW_HANS/resources.json'''
  +
  +
Multiple directories are supported. For example:
  +
* locales/common_resources/en/resources.json
  +
* locales/common_resources/fr_FR/resources.json
  +
* locales/common_resources/zh_TW_HANS/resources.json
  +
* modules1/locales/en/resources.json
  +
* modules1/locales/fr_FR/resources.json
  +
* modules1/locales/zh_TW_HANS/resources.json
  +
  +
For full details, please refer to [[On_Boarding_an_LRM_Project#Build]]
   
 
== JSON File Format ==
 
== JSON File Format ==
 
JSON files are like XML files: They can have complex schemas to represent complex objects. For translation purposes, LRM supports a restricted subset of the overall JSON format.
 
JSON files are like XML files: They can have complex schemas to represent complex objects. For translation purposes, LRM supports a restricted subset of the overall JSON format.
 
   
 
===Arrays are not allowed in the context of JSON files as resource bundles===
 
===Arrays are not allowed in the context of JSON files as resource bundles===
String references in the code, from an i18n point of view, is unmanageable for JSON arrays. In addition, many L10n vendors do not support JSON arrays. (Sample JSON files are located in LRM-Server-2.1/''samples/JSON_Examples'')
+
String references in the code, from an i18n point of view, is unmanageable for JSON arrays. In addition, many L10n vendors do not support JSON arrays. (Sample JSON files are located on the server in <code>/var/lib/jenkins/lingoport/lrm-server-<version>/samples/JSON_Examples </code>)
   
 
===There is only one key/value per line.===
 
===There is only one key/value per line.===
Line 54: Line 115:
 
</pre>
 
</pre>
   
** Invalid
+
* Invalid
 
<pre>
 
<pre>
 
"key1":0,
 
"key1":0,
 
"key1": true
 
"key1": true
 
</pre>
 
</pre>
  +
=== Keys must be unique===
 
  +
In order to prevent a duplicate key error all keys must be unique.
== Example of LRM Supported JSON Files ==
 
  +
* Valid
 
=== Typical ===
 
This file, named resources_en.json, looks similar to a .properties file, with a key/value pair on each line. This is the most common and simple file to handle:
 
 
<pre>
 
<pre>
  +
"key1":"0",
{
 
  +
"key1_1" : {
"access-groupAccess.Open": "Open",
 
  +
"one":"one"
"access-groupAccess.InvitationOnly": "Invitation Only",
 
  +
}
"access-groupAccess.RequestToJoin": "Request To Join",
 
"title-GET-REQUESTED-INVITATIONS-FAILED": "Get request status failed",
 
"message-GET-REQUESTED-INVITATIONS-FAILED": "Could not get the status of request to join group",
 
"title-REQUEST-JOIN-GROUP-FAIL": "Request to join failed",
 
"message-REQUEST-JOIN-GROUP-FAIL": "Could not send request to join. Please try again",
 
"all_volunteers" : "All Volunteers",
 
"access-OPEN" : "Open",
 
"access-INVITATION_ONLY" : "Invitation Only",
 
"access-REQUEST_TO_JOIN" : "Request To Join"
 
}
 
 
</pre>
 
</pre>
   
  +
* Invalid
=== Typical with Keys for Comments===
 
This file, named resources_en.json, looks similar to a .properties file, with a key/value pair on each line. This is the most common and simple file to handle:
 
 
<pre>
 
<pre>
  +
"key1":"0",
{
 
  +
"key1": {
"_description_groupAccess.Open", "To help users with the Open in the top window",
 
  +
"one":"one"
"access-groupAccess.Open": "Open",
 
  +
}
"access-groupAccess.InvitationOnly": "Invitation Only",
 
"access-groupAccess.RequestToJoin": "Request To Join",
 
"title-GET-REQUESTED-INVITATIONS-FAILED": "Get request status failed",
 
"message-GET-REQUESTED-INVITATIONS-FAILED": "Could not get the status of request to join group",
 
"title-REQUEST-JOIN-GROUP-FAIL": "Request to join failed",
 
"message-REQUEST-JOIN-GROUP-FAIL": "Could not send request to join. Please try again",
 
"all_volunteers" : "All Volunteers",
 
"access-OPEN" : "Open",
 
"access-INVITATION_ONLY" : "Invitation Only",
 
"access-REQUEST_TO_JOIN" : "Request To Join"
 
}
 
 
</pre>
 
</pre>
  +
  +
=== Language Tags ===
  +
  +
A language tag is the language code of the resource file's locale and located at the top of the file. When a LRM prep kit file is imported, the language tag will reflect the locale of the imported file.
  +
  +
{
  +
"en": {
  +
"nestedKey": {
  +
"login": "Log In",
  +
"logout": "Log Out",
  +
"name": "Name"
  +
}
  +
}
  +
}
  +
  +
''' LRM ignores the JSON language tag when determining the resource keys '''
  +
  +
If a JSON file contains nested keys, then LRM ''flattens out'' the structure so that a unique key can be created. Each field name within the nested object has a separator of '''''_^o^_'''''. The language tag is not included in the creation of the unique key. The following is an example of the unique LRM resource keys created from the above JSON file.
  +
  +
The key/value pairs created by LRM are:
  +
  +
{| class="wikitable" style="border: none; background: none;"
  +
| rowspan="4" style="border: none; background: none;"|
  +
! scope="col" | Key
  +
! scope="col" | Value
  +
|-
  +
| nestedkey_^o^_login || Log In
  +
|-
  +
| nestedkey_^o^_logout || Log Out
  +
|-
  +
| nestedkey_^o^_name || Name
  +
|-
  +
|}

Latest revision as of 19:35, 22 July 2020

JSON Resource Bundles

Well-formed JSON is required and specified by http://www.ietf.org/rfc/rfc4627.txt. JSON can in effect have any 'schema' and only some subset of JSON makes sense for Localization. JSON resource bundles are supported starting with LRM 2.1. The details of the LRM supported format is provided below.

JSON files are increasingly used with JavaScript as a means to capture strings to be translated.

Example of LRM Supported JSON Files

Typical

This file, named for instance errors_en.json, looks similar to a .properties file, with a key/value pair on each line. This is the most common and simple file to handle:

{
  "title": "Woops!",
  "message": "Something went wrong.  Try again later."
}

Typical with Keys for Comments

This file, named for instance resources_en.json, looks similar to a .properties file, with a key/value pair on each line. The first line has a key which start with an underscore, indicating a description for the key just after it. The text for "_description_groupAccessOpen" will not be translated:

{
  "_description_groupAccessOpen", "To help users with the Open in the top window",
  "groupAccessOpen": "Open",
  "groupAccessInvitationOnly": "Invitation Only",
  "groupAccessRequestToJoin": "Request To Join",
  "all_volunteers" : "All Volunteers"
}

Objects

The keys must be unique within a file. Sometimes, objects allow for an organization within the files which matches the developers' code.

{
  "the_cat": "The Cat",
  "dogs": {
        "pitbull": "A pitbull",
        "collie": "A collie",
        "small_dogs": {
                "poodle": "A teacup poodle"
        }
  }
}


JSON File Structure

As with all resource files, LRM requires JSON files to adhere to specific standards in naming and directory structure in order to detect and import changes.

The locale of the target files must be made explicit through either a pattern of file names or a pattern of directory names. Please use the same pattern consistently - as only one pattern is supported per file extension per project.

This is described in depth at On_Boarding_an_LRM_Project#Build

A few examples for reference:

Locale Defined in File Name

  • resources_en.json or resources_en_US.json,
  • resources_fr.json or resources_fr_FR.json, etc.

With multiple directories such as:

  • locales/common_resources_en.json
  • modules1/locales/module1_messages_en.json

Locale Defined in Directory Name

  • en/resources.json, fr_FR/resources.json, zh_TW_HANS/resources.json,

OR

  • modulename_en/resources.json, modulename_fr_FR/resources.json, modulename_zh_TW_HANS/resources.json

Multiple directories are supported. For example:

  • locales/common_resources/en/resources.json
  • locales/common_resources/fr_FR/resources.json
  • locales/common_resources/zh_TW_HANS/resources.json
  • modules1/locales/en/resources.json
  • modules1/locales/fr_FR/resources.json
  • modules1/locales/zh_TW_HANS/resources.json

For full details, please refer to On_Boarding_an_LRM_Project#Build

JSON File Format

JSON files are like XML files: They can have complex schemas to represent complex objects. For translation purposes, LRM supports a restricted subset of the overall JSON format.

Arrays are not allowed in the context of JSON files as resource bundles

String references in the code, from an i18n point of view, is unmanageable for JSON arrays. In addition, many L10n vendors do not support JSON arrays. (Sample JSON files are located on the server in /var/lib/jenkins/lingoport/lrm-server-<version>/samples/JSON_Examples )

There is only one key/value per line.

  • Valid
      "key1":"This is my value for key1",
      "key2":"This is my value for key2"
  • Invalid
      "key1":"This is my value for key1","key2":"This is my value for key2"

End-object character (curly bracket) may not exist on the same line as a key/value

  • Valid
      "keys": {
         "key1":"This is my value for key1"
       }
  • Invalid
      "keys": {
         "key1":"This is my value for key1"}

Values associated with a key must be a string

Numeric and boolean values are not allowed.

  • Valid
      "key1":"0"
  • Invalid
      "key1":0,
      "key1": true

Keys must be unique

In order to prevent a duplicate key error all keys must be unique.

  • Valid
     "key1":"0",
     "key1_1" : {
         "one":"one"
      }
  • Invalid
     "key1":"0",
     "key1": {
        "one":"one"
      }

Language Tags

A language tag is the language code of the resource file's locale and located at the top of the file. When a LRM prep kit file is imported, the language tag will reflect the locale of the imported file.

  {
    "en": {
       "nestedKey": {
          "login": "Log In", 
          "logout": "Log Out",
          "name":  "Name"
        }
     }
  }

LRM ignores the JSON language tag when determining the resource keys

If a JSON file contains nested keys, then LRM flattens out the structure so that a unique key can be created. Each field name within the nested object has a separator of _^o^_. The language tag is not included in the creation of the unique key. The following is an example of the unique LRM resource keys created from the above JSON file.

The key/value pairs created by LRM are:

Key Value
nestedkey_^o^_login Log In
nestedkey_^o^_logout Log Out
nestedkey_^o^_name Name