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 processing of <br> tags when exporting #101

Open
alexshink opened this issue Feb 3, 2021 · 2 comments
Open

Incorrect processing of <br> tags when exporting #101

alexshink opened this issue Feb 3, 2021 · 2 comments

Comments

@alexshink
Copy link

Hello! First of all, thanks for your work.

What is the problem?

When you run the export command for a .vue file, translation strings containing the <br> tag are not generated correctly in .po files: </br> is added at the end of any such line. Therefore, the translation does not work because the keys are not the same.

Source string in template:
image

String in .po file after export:
image

Expected Behavior

An extra closing </br> tag should not be generated.

Environment

Windows 10
Vue 3.0.0
@vue/cli 4.5.10
easygettext 2.16.1

@alexshink
Copy link
Author

I found that the problem is with the handling of the cheerio that is started with the xmlMode: true parameter. After disabling this option, tag processing is correct. It's strange that this option is enabled by default, because we mainly parse HTML rather than XML.

It might be worth implementing the ability to control this parameter when invoking the export command by specifying the corresponding parameter in the command?

extract.js:

image
image

@romainletendart
Copy link

Hi Alex,

Thank you very much for reporting this issue.
Currently, you're right in saying that easygettext defaults to XML parsing. It is not that strange as this works well for XHTML.
For less strict HTML, this won't work as <br> is considered an opening tag that needs its closing tag.
However, if you turn <br> in your example into <br/> (self-closing), this will work.

I agree with you that we should have a more flexible approach to allow both XHTML and HTML to work in this case.
Hence the CLI option is a good idea.

May I suggest you open a PR on this matter?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants