JSON textunits should have a global ID

Description

The textunit resIds for JSON are generated with contentHash, which means the TextFlowTargets for:

"thing": { "title":"a string" "subject":"a string" }

will be the same.
This may not be desirable, as there is no context or convention that says they are they same in the way of translatable text.

There should be a means of getting the global id, e.g. thing.title, and using that in the resID.
See test JSONAdapterTest:testDuplicateContent.

Activity

Show:

Former user 28 May 2018 at 13:53

It appears that, by using the parameter

p.fromString("extractIsolatedStrings.b=true\nuseFullKeyPath.b=true");

I can get a decent path that for

{ "test": { "title": "Line One", "test1": { "title": "Line Two", "test2": { "test3": { "ID": "Line Three", "testarray": ["First", "Second"] } } } } }

I get

TU ID: tu1 TU Name: null/test/title Content, Line One TU ID: tu2 TU Name: null/test/test1/title Content: Line Two TU ID: tu3 TU Name: null/test/test1/test2/test3/ID Content: Line Three TU ID: tu4 TU Name: null/test/test1/test2/test3/testarray Content: First TU ID: tu5 TU Name: null/test/test1/test2/test3/testarray Content: Second

This makes it easy to handle things well enough, though I either need to have some magic with standalone strings (First, Second) or take them out of consideration.

Sean Flanigan 14 February 2017 at 07:25

For arrays, we should probably use indices, eg

thing.array[0].title

.

If we make the resIds based on a unique path, we should probably avoid using a content hash entirely. This would allow us to track the identity of a string over time, even with changes in the English text, as we do for properties files (where the property key is the resId). This would allow for smarter translation memory logic.

Ready for Release

Details

Assignee

Reporter

Labels

Tested Version/s

Components

Fix versions

Priority

More fields

Created 14 February 2017 at 04:32
Updated 19 July 2018 at 06:37
Resolved 19 July 2018 at 06:37

Flag notifications