I know that you cannot have multi-line json files.
At the moment I am breaking the text I need to be translated into logical blocks. However, the problem is that they are still very long lines, and it’s a horrible experience trying to edit them in VS Code.
Is there another way of handling large blocks of text in i18N?
This is one of the blocks I’m fighting with at the moment !
"home": {
"para1": "The management system for trading in Raw Cashew Nuts",
"title": "Home",
"l1":"This is a comprehensive system to manage the purchases of cashews (or other commodities), their arrival at your warehouse and shipping them out to your customers. The system was developed after having practical experience of exporting many thousands of tons of raw cashews from origin.",
"l2":"The sytem was developed to reduce or completely eliminate:",
"l3":"Poor stock control in the warehouse - scraps of paper partially recording stock entries etc.",
"l4":"Arguments with the inspector over which lots have been approved",
"l5":"Employees wasting time producing the Packing List, not checking the details and sending incorrect documents to the bank",
"l6":"Preparing draft Bills of Lading in Word, making mistakes, waiting for the customer to approve the draft, and then trying to find the email with the correct draft attached to it to send to the shipping company.",
"l7":"Because the buyer cannot see the supporting documents until they are emailed to him; usually days after issue, any mistakes are not picked up quickly enough. This can often lead to the customer asking for a change to the documents which might even have to be retrieved from the bank.",
"l8":"Many other issues arising out of poor management and sloppy work which causes delays to getting the documents to the bank and the customer all delaying the time it takes to receive payment.",
"l9":" Your buyers can log in to the system and see the shipping documents you have prepared. They can formally approve your draft documents including the Bill of Lading before you ask the shipping company to generate the originals.",
"l10":"Scanned copies of all the principal shipping documents are stored per Bill of Lading.",
"l11":"Whoever manages your warehouse, whether it be one of your employees or a third party warehouse manager has independent access to the system. Only the warehouse manager can receive goods into stock or dispatch them to the container terminal.",
"l12":"The same is true for the quality inspector. Only he is able to record the quality of the cashews.",
"l13":"This system allows your customer to completely trust you. He knows that if the quality inspector works for him, only he can record the quality. Further he also has the knowledge that if the warehouse manager is the Customer's representative or a third-party collateral manager, that only he can update the stocks.",
"l14":"The system can also automatically generate a draft Bill of Lading, the Packing List and issue a purchase order to your supplier."
},
JSON doesn’t support multiline strings. Period. That’s sad but true.
There is a solution to your issue though. Just use yml files instead for translations.
It supports multiline strings like this:
// standard
key: >
Your long
string here.
// this preserves \n
key: |
### Heading
* Bullet
* Points
JSON doesn’t support multiline strings, but https://json5.org/ does. And since json5 is a superset of json, it is perfectly safe to replace the JSON parser in the library with JSON5.
I havent tried it out yet but the mentioned npm package just provides a backend same as the xhr one. So in theory just switch it out. As for html I guess it should. Give it perhaps a testdrive on a minimal demo set
Fair statement. It was just a quick search and seems there are more yml loaders available.
EDIT: I’ve tried it now out myself and looking at the code of the yml backend it seems that was way back for v1/2. So definitely out-of-date. Sry @jeremyholt but it seems you’d have to write your own backend with YML.
What I’ve quickly tried, and it seems to work, is just to leverage either the xhr backend or the builtin from the i18n plugin and do the following on configuration:
// npm install yamljs
// npm install --save-dev @types/yamljs
import {parse} from "yamljs";
// in your plugin configuration
return instance.setup({
backend: { // <-- configure backend settings
loadPath: './locales/{{lng}}/{{ns}}.yml', // <-- switch to YML,
parse // <--- switch out the parser for the yml one
},
attributes: aliases,
lng : 'de',
fallbackLng : 'en',
debug : true,
});
So pretty much the same as you suggested with json5 @khuongduybui. Seems to work so far but it’s really just a quick test so take it for a proper testdrive @jeremyholt
The main reason I used XHR backend is so that translations would not be bundled. That makes the initial bundle smaller and I can load translations on demand. Its nice to see a way to use JSON5 without gulp!
Could you share the gulp taks you’ve created alongside how you included it in the other existing aurelia tasks? I guess what you did is to create a conversion task, which gets called in sequence with the au build task. But it would be nice to have a working example here so that everybody who’s interested can take a look at it.
Also I fully agree with your reasoning about XHR backend. For the projects I did with i18n I’ve always used it for the exact same reason. I definitely don’t see a lot of value in bundling translations upfront, specifically in environments with large translation files and lots of languages. Nearly every user sticks to his language of choice and the XHR requests get cached, so it’s slow only the first time. But in the bundled case every user would have to load everything upfront (e.g 5 languages in one of my apps) whereas 4 of those would be a total waste of bandwith for him. Moreover, since it’s included in the bundle, every update to a language would cause the user to re-download the whole bundle and invalidate the cache, whereas with XHR only the respective languages file get’s invalidated and re-upped.
