Difference between revisions of "LRM JSON Support"

From Lingoport Wiki
Jump to: navigation, search
(Example of Supported .json Files)
Line 1: Line 1:
 
LRM supports those .json files which makes sense for translation. Not all .json files do.
 
LRM supports those .json files which makes sense for translation. Not all .json files do.
 
== Example of Supported .json Files ==
 
== Example of Supported .json Files ==
JSON extension is supported in the Lingoport Manager (LRM). Well-formed JSON is required and specified by http://www.ietf.org/rfc/rfc4627.txt. In order to detect and import changes, LRM requires JSON files to also adhere to the following standards.
+
JSON extension is supported in the Lingoport Resource Manager (LRM). Well-formed JSON is required and specified by http://www.ietf.org/rfc/rfc4627.txt. In order to detect and import changes, LRM requires JSON files to also adhere to the following standards.
 
* The json files must follow this naming convention: '''filename_<locale>.json''' or '''filename_<locale>_<country>.json'''. For example, '''resources_en.json''' or resources_en_US.json, '''resources_fr.json''' or resources_fr_FR.json, etc.
 
* The json files must follow this naming convention: '''filename_<locale>.json''' or '''filename_<locale>_<country>.json'''. For example, '''resources_en.json''' or resources_en_US.json, '''resources_fr.json''' or resources_fr_FR.json, etc.
 
* '''If you can, avoid duplicate file names'''. Duplications incur more prep kits than necessary.
 
* '''If you can, avoid duplicate file names'''. Duplications incur more prep kits than necessary.
   
 
=== Simple is Best ===
 
=== Simple is Best ===
A file with <b>one key value per line</b>, with some possible semantics in the key, is the preferred way to have .json resource bundles. There is no structure (no objects) to the file, so changing keys, moving them around, does not affect whatever outstanding translation will be returned at a later date with a different structure.
+
A file with <b>one key value per line</b>, with some possible semantics in the key, is the preferred way to have .json resource files. There is no structure (no objects) to the file, so changing keys, moving them around, does not affect whatever outstanding translation will be returned at a later date with a different structure.
 
<b>resources_en.json</b>
 
<b>resources_en.json</b>
 
{
 
{

Revision as of 21:59, 1 February 2017

LRM supports those .json files which makes sense for translation. Not all .json files do.

Example of Supported .json Files

JSON extension is supported in the Lingoport Resource Manager (LRM). Well-formed JSON is required and specified by http://www.ietf.org/rfc/rfc4627.txt. In order to detect and import changes, LRM requires JSON files to also adhere to the following standards.

  • The json files must follow this naming convention: filename_<locale>.json or filename_<locale>_<country>.json. For example, resources_en.json or resources_en_US.json, resources_fr.json or resources_fr_FR.json, etc.
  • If you can, avoid duplicate file names. Duplications incur more prep kits than necessary.

Simple is Best

A file with one key value per line, with some possible semantics in the key, is the preferred way to have .json resource files. There is no structure (no objects) to the file, so changing keys, moving them around, does not affect whatever outstanding translation will be returned at a later date with a different structure.

resources_en.json
{
 "site_heading": "Where can I find more information on the site?",
 "site_subHeading2": "Search",
 "enableGeo": "Enable location services in your browser to load local help results.",
 "findButton": "Find",
 "gettingStarted_title": "Getting Started",
 "gettingStarted_subHeading": "Here are the main things you need to know as you
get started.",
 "logging_off_account": "Log off"
}

If you want complexity

Caveat JSON structure changes can lead to problems with project on-boarded for file deltas (v. Full Files).

In what format should JSON Files be for LRM Handling ?

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):

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

Sample LRM Project Definition File for .json

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<lrmconf>
 <model-version>3.0.18</model-version>
 <project-name>search</project-name>
 <project-desc>Search project</project-desc>
 <group-name>Lingoport</group-name>
 <top-level-dir>/var/lib/jenkins/jobs/Lingoport.search/workspace</top-level-dir>
 <detect-errors>
   <missed-trans-error>0</missed-trans-error>
   <parameter-mismatch-error>1</parameter-mismatch-error>
 <track-back-locale>br</track-back-locale>
 <target-locales>
   <locale>es</locale>
   <locale>fr</locale>
   <locale>ja</locale>
 </target-locales>
 <default-locale>en</default-locale>
 <resource-extensions>
   <resource-extension>
     <extension>json</extension>
     <file-name-pattern>*_l-c-v</file-name-pattern>
     <use-pattern-on-dflt-locale>1</use-pattern-on-dflt-locale>
     <file-location-pattern/>
     <use-location-pattern-on-dflt-locale>0</use-location-pattern-on-dflt-locale>
     <base-file-encoding>UTF-8</base-file-encoding>
     <localized-file-encoding>UTF-8</localized-file-encoding>
     <parameter-regex-pattern><![CDATA[\{\w+\}|%[ds]]]></parameter-regex-pattern>
   </resource-extension>
 </resource-extensions>
 <dirset>
   <includes>
     <include-dir>**/**</include-dir>
   </includes>
   <excludes>
     <exclude-dir-file/>
     <exclude-dir-file>**/*_eo.json</exclude-dir-file>
     <exclude-dir-file>**/*_eo__*.json</exclude-dir-file>
     <exclude-dir-file>**/*_br.json</exclude-dir-file>
     <exclude-dir-file>**/LRMScans/**</exclude-dir-file>
     <exclude-dir-file>**/GlobalyzerScans/**</exclude-dir-file>
     <exclude-dir-file>**/sonar-project.properties</exclude-dir-file>
   </excludes>
 </dirset>
 </lrmconf>