• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 65 subscribers
  • Views 6513 views
  • Users 0 members are here
Options
Related

Comments in JSON / RESJSON

PB Localization

Hi,

we try to figure out the way of introducing comments in JSON files that would be recognized as such by the parser and thus put in the "Comments" column in Passolo (2015).
We have tried to apply the solutions presented here:
producthelp.sdl.com/.../JSONAddin.htm
But we have encountered the following issues:
(1) Adding comments using double slashes works great, but as explained in the article, this results in having an invalid JSON file for the source content.
We are thinking of creating JSON files with comments, and then saving two copies of them: one containing comments - for translation purposes and another one with comments being automatically deleted for use as a regular JSON file with English content.
The problem is that it would just add some more complexity to a project that is already very complex.

(2) Converting the files to the resjson format works great as well, but it does not allow to have any nested elements.

Does someone know if there is some other way to put comments in JSON files, for them to go in the "Comments" column in Passolo while keeping valid JSON format of the source file? Or to process resjson files containing nested elements?

Thanks.
Piotr
Rate translation
×
Suggest better translation
×
Parents
  • 0
    Hello Piotr,

    With the selection of JSON as the resource file format your developers have chosen a standard (http://www.json.org), that doesn’t support comments. Our solution described in producthelp.sdl.com/.../JSONAddin.htm is just a small work-around for those users that do not get problems in their own framework with commented JSON files that do not comply 100% with the standard.

    Your post already contain one solution which is maintaining 2 copies. Yes, this makes it more complex but this can't be prevented. I can think of other solutions but all have its complexity like
    • Maintaining and importing comments from a different (non JSON) file using a customization while keeping the original valid JSON file
    • Enhancing your resource framework to support commented JSON files
    In the end it would also be possible to use another resource file format (like XML) where you can easily embed and handle comments.

    I would not suggest to use the second (2) method if you need support of nested elements. Microsoft has introduced a special syntax into RESJSON that support comments but it doesn’t work support nested elements.

    The basic problem is that developers usually don’t care about the localization process while localization manager need as much context information for translators as possible. If the selected resource file format is not able to store and handle this context information your organization has to conciliate between the development requirements and the localization requirements. This should be easy as the success of a company is usually based on selling a product in many countries. So developers should create translation-friendly resources.
Reply
  • 0
    Hello Piotr,

    With the selection of JSON as the resource file format your developers have chosen a standard (http://www.json.org), that doesn’t support comments. Our solution described in producthelp.sdl.com/.../JSONAddin.htm is just a small work-around for those users that do not get problems in their own framework with commented JSON files that do not comply 100% with the standard.

    Your post already contain one solution which is maintaining 2 copies. Yes, this makes it more complex but this can't be prevented. I can think of other solutions but all have its complexity like
    • Maintaining and importing comments from a different (non JSON) file using a customization while keeping the original valid JSON file
    • Enhancing your resource framework to support commented JSON files
    In the end it would also be possible to use another resource file format (like XML) where you can easily embed and handle comments.

    I would not suggest to use the second (2) method if you need support of nested elements. Microsoft has introduced a special syntax into RESJSON that support comments but it doesn’t work support nested elements.

    The basic problem is that developers usually don’t care about the localization process while localization manager need as much context information for translators as possible. If the selected resource file format is not able to store and handle this context information your organization has to conciliate between the development requirements and the localization requirements. This should be easy as the success of a company is usually based on selling a product in many countries. So developers should create translation-friendly resources.
Children
  • 0 in reply to Achim Herrmann
    Hi Achim,

    Thank you very much for your reply.

    I understand that json as such does not support comments.
    Nevertheless, we have now a situation in which there are two ways we can get ALMOST there:
    We have the addin that:
    - can recognize and support comments, if the format is RESJSON;
    - can recognize and support nested elements, if the format is JSON.
    So wouldn't it be possible to just integrate the resjson style comments into the JSON addin?
    Or to add some more customization options to the JSON addin (Mappings etc.)?

    Of course we can think of different ways of preprocessing files before adding them to a Passolo project or changing the resource format (which is a lot easier to do at early stages of product development, so we'll keep that in mind for any future projects). But if so much has been already done, maybe it'd be possible to go one step further?

    Thanks,
    Piotr
  • 0 in reply to Achim Herrmann
    Hi Achim,
    just one more question related to this:
    I have managed to set up a text parser that could do the trick: it will support both RESJSON type comments and the nested content. The nested content is treated as another type of a resource.
    So, the only problem I get right now is the fact that the resource delimiter in Passolo allows me only to define the BEGINNING of a given resource and that all the resources are at the same level.
    If my file structure is:
    - main content
    -- nested content
    ---nested content level 2
    - main content
    the main content at the end is treated as the continuation of "nested content level 2" and all the nested content items are at the same level as the main content.
    The structure I get in Passolo is as follows:
    - main content
    - nested content
    - nested content level 2 + the second part of the main content
    Do you think there's something more I can do within the text parser to get the right resources structure?

    Thanks.
    Piotr