Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect 'state' attribute "needs-translation" for XLIFF 2.0 #50

Closed
antpyykk opened this issue Aug 3, 2020 · 8 comments · Fixed by #52
Closed

Incorrect 'state' attribute "needs-translation" for XLIFF 2.0 #50

antpyykk opened this issue Aug 3, 2020 · 8 comments · Fixed by #52
Labels
bug Something isn't working shipped Issue is available in the public release.

Comments

@antpyykk
Copy link

antpyykk commented Aug 3, 2020

Hello Rob


There are in total four states defined in XLIFF 2.0 specification:

  • initial - indicates the segment is in its initial state
  • translated - indicates the segment has been translated
  • reviewed - indicates the segment has been reviewed
  • final - indicates the segment is finalized and ready to be used

The state attribute does not contain needs-translation nor needs-adaption like 1.2 spec.
Either initial state could be used or alternatively a custom subState can be defined.


Just a minor inconvenience in an otherwise fantastic extension.

-Antti

@rvanbekkum
Copy link
Owner

Hi @antpyykk,
Thank you for filing this issue! I will look into it.

@rvanbekkum rvanbekkum added the bug Something isn't working label Aug 3, 2020
@rvanbekkum
Copy link
Owner

rvanbekkum commented Aug 3, 2020

Hi @antpyykk,
I have made some changes to account for the states defined in the XLIFF 2.0 specification in the features/50-xlf2-states branch. You can find more information about the changes in the CHANGELOG in this branch:

CHANGELOG.md

  • Better XLIFF 2.0 support:
    • state attribute on segment nodes instead of target nodes.
    • state and subState used:
      • needs-translation -> initial with no sub-state
      • needs-adapatation -> translated with sub-state configurable with setting xliffSync.needsWorkTranslationSubstate.
      • translated -> translated with no sub-state.
    • Let xliffSync.fileType = xlf2 work with file-extension xlf.

Could you let me know if you can spot anything wrong or missing with these changes?

@rvanbekkum rvanbekkum added the in-progress One of the contributors is working on this. label Aug 3, 2020
@antpyykk
Copy link
Author

antpyykk commented Aug 4, 2020

Excellent work @rvanbekkum . You sure work fast.

My only point would be to mention the default subState required for translation. Any reason for using poedit:fuzzy?

vsc-xliff-sync/package.json

Lines 154 to 159 in 37f69c9

"xliffSync.needsWorkTranslationSubstate": {
"type": "string",
"default": "poedit:fuzzy",
"description": "Specifies the substate to use for translations that need work in xlf2 files.",
"scope": "resource"
},

Other than that, this seems like it fixes the issue 👍

@rvanbekkum
Copy link
Owner

Thanks for your reply.

About the default subState:
I currently set it to the value that the application "POEdit" adds to translations that you mark as 'needs work'.
What do you think might be a good default value for this setting? Do you think we should set it to something more general (e.g., "needsWork" or something similar) and let people customize it themselves in their user settings?

@antpyykk
Copy link
Author

antpyykk commented Aug 4, 2020

I really don't have an opinion on this.

Quick search regarding poedit:fuzzy would indicate it marks the translation for automatic fuzzy translation - not neccessarily as "needs work".

GitHub code search also didn't reveal many good candidates for naming the subState

Either introduce a custom namespace used exclusively by vsc-xliff-sync or keep the current poedit value. Nevertheless I think it will be overwritten by user settings.

@antpyykk
Copy link
Author

antpyykk commented Aug 7, 2020

@rvanbekkum if there's no further comments regarding this, I guess we could close the issue?

@rvanbekkum
Copy link
Owner

Hi @antpyykk,
The changes didn't make it into the master branch and the VS Marketplace just yet.
I would prefer to close it as soon as the changes make it into the master branch 😉.

@rvanbekkum
Copy link
Owner

Changes for this have been shipped in version 0.5.0.
Thanks again for reporting the issue!

@rvanbekkum rvanbekkum added shipped Issue is available in the public release. and removed in-progress One of the contributors is working on this. labels Aug 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working shipped Issue is available in the public release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants