spdx-3-model
spdx-3-model copied to clipboard
Fix paragraph in zh-Hans trans. in NoAssertionElement
This is a PR against support/3.0 branch.
What this PR does:
-
In Simplified Chinese translation of the Description section, add the missing blank line after the bullet list in Markdown source to enforce the correct formatting.
-
The last paragraph of the Description should be separated from the last item in the bullet list.
-
English text for comparison:
-
-
Restored the original typographic emphasis of classes and entry values.
Current Simplified Chinese (zh-Hans) text:
例如,关系
relationshipType=ancestorOf、from=Element1和to=NoAssertionElement明确表示不对Element1的任何潜在后代作出任何断言。Current English (en) text :
For example, a Relationship with
relationshipType="ancestorOf",from=Element1, andto=NoAssertionElement is explicitly expressing that no assertion is being made about any potential descendants of Element1.it is possible that the rationale for current style of English text is:
- relationshipType, from, to: in
fixed-width font, indicates that they are class or property or datatype. - ancestorOf: in between "quotation marks", indicates that is is an entry value (of RelationshipType).
- Element1, NoAssertionElement: in regular font, without any typographic device, indicates that they are instances.
- relationshipType, from, to: in
--
Btw, on (2), although the style is different from the original English text, the Simplified Chinese translators are actually trying to enforce more consistent style across all of its text (see other files in the model for comparison). Classes and properties are all in fixed-width font across zh-Hans. Texts in English version, by contrast, is less consistent in the application of styles.
We may have to discuss and agreed upon consistent style choice, documented it, and apply it to every languages. This has been raised before, during the 3.0.1 editorial process for ISO submission and postponed to 3.1 instead:
- https://github.com/spdx/spdx-spec/issues/1000
@gomico @ZhengZhenyu while point (2) may need longer discussion, I think point (1) is obvious.
If you can approve point (1) fix, we can selectively merge only point (1) for now.
Sorry for the late reply. Can confirm that modification in point 1 is correct and should be merged.
Thanks. I have created another PR (#1021) to fix only point 1 (newline) and will leave this one open for point 2 (style) discussion.
@bact - should this be merged? If so, please rebase otherwise close.
We can close for now