fix The Korean sentence order in Authorship description#2947
fix The Korean sentence order in Authorship description#2947chrisknoll merged 2 commits intoOHDSI:masterfrom
Conversation
Signed-off-by: Juyoung Kim <tandara0@gmail.com>
|
Is there any way you can combine those multiple elements into one templated field like: Such that we create one element to contain the full sentence of what the created by message shoudl be (and separately, the modified one). This is the code: The issue is the content of the message is being broken apart by multiple spans and databinds (and multiple i18n tokens). Would it be possible to restructure this into just 2 spans with 2 i18n tokens ( This would solve the problem of language structure by encapsulating the entire sentence into one block. Would this be possible for you to do? I think I'd prefer a solution that reduces the number of I18N tokens in our resources instead of adding new ones that only apply in certain contexts. |
|
Dear @chrisknoll, I agree to reduce the elements of the authorship components. before: after: this change will be applied the file messages_en.json in OHDSI/WebAPI git. messages_ko.json: messages_ru.json: messages_zh.json: lastly, the authorship.html in this Atlas git will be changed like: If the codes above are the same as you think, I will commit the codes again. |
|
Yes, that was exactly what I was thinking. Reduces i18n elements and simplifies code. I think we have to handle the 'version created' case, which is displayed when you are looking at a version of an asset. It should follow the same pattern to say |
|
I tried adding preview element and removing versionCreated in the authorship component. messages_en.json: cohort-definition-manager.js : Like above code changes of cohort-defined-manager.js, all javascript with getAuthorship() function defined should be changed. authorship.js: authorship.html: Finally, the createdText is no more used, and can be eliminated. |
|
Ok, thanks for explaining this, and seems fine. Only thing I would change is on the naming: the 'preview' is probably better termed a 'prefix' or 'preamble', prefix is probably fine enough (as it represents something inserted before something else). while preamble is more like a introduction to a story. So I'd suggest prefix over preview (preview has different meaning in the application where you can 'preview' a concept set change before commit). |
|
Although I don't want to insist on my codes, I think I have to add a explanation as there is possible that you misunderstood something. I will show you the changed json of messages_ko.json messages_ko.json: As you can see in this json, the previewText is not positioned in front of the sentense, in korean. I agree the name 'preview' is not the best. So, just think about it one more time and make a decision, then I'll follow any decision. |
|
Ok, thanks for the clarification. So I think in order to to deal with different sentence structure across languages, we need to think in terms of labels. I think i understand that you are saying that the 'preview' element positioning depends on langauge. So i think we need to think about making it a complete sentence (for the preview label) so it handles the differences. I don't use the version history so much that I don't know if it even matters that we have to have special messaging about authorship for a preview vs. the normal, non-version-history view. I would think that when the version history shows up, you have something in the dialog box or in the header that says 'this is a version'. So could we remove the preview text from the authorshp component completely? |
Signed-off-by: Juyoung Kim <tandara0@gmail.com>
|
Sure. The WebAPI PR: OHDSI/WebAPI#2382 Please, review them. |
This commit is about the issue: OHDSI/WebAPI#2381
And the commit involved in WebAPI: OHDSI/WebAPI#2382