-
Notifications
You must be signed in to change notification settings - Fork 73
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
[RFC] 0007 Properties File Encoding #168
Conversation
change to 0007 because 0006 is already present
The `ui5-builder` should offer a task called `encodePropertiesFiles` which escapes all special characters in unicode using the unicode escape sequence `\uXXXX`. | ||
It should use a processor called `stringEscaper` which escapes special characters in files and is used within the task to operate only on `*.properties` files. | ||
The processor offers a function called `escapeNonAsciiAsUnicode` which performs the unicode escaping. | ||
The task should be run first (before `replaceCopyright`) for all types. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm... isn't adding new standard tasks always changing the ordering of the custom task as well?
So if somebody already wanted to be "first" and has registered a custom task before replaceCopyright
, they are now only 2nd...
Not sure if we see that as a problem, but the ordering of tasks seems important since their results might depend on eachother, right?
- Include reviews - Fix MD warnings
Adjust content because files' content should always be escaped.
Adjust to latest discussion regarding encoding parameter
Adjust to latest changes in ui5-builder
would it make sense to later on introduce an auto-detection feature such as: |
I like that this module also returns a confidence score. But this already shows the problem: some character codes exist in multiple encodings. I definitely don't want to identify an encoding wrong, which would result in the wrong characters being used in a translation file. So for me, the confidence score would need to be near 100% to be acceptable to work with. But even in cases where a file can be identified 100% correctly, if it changes and the confidence score drops we would need to prompt the developer to specify the encoding anyways. This situation might occur in case of automated commits from a translation system that add new special characters. This would then break the build. I don't like that possibility 😕 |
@RandomByte: this was exactly the reason why we always tried to avoid sniffing in the Java tooling and server, too. |
Improve motivation section by being more specific about the encoding options
This could also lead then to a problem when some files are served with one encoding and others with another one^^ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
This RFC looks pretty much done to me. Any further feedback from any of you @Thodd, @tobiasso85, @codeworrior? |
Looks good to me |
Also LGTM |
Please squash and merge! |
Released with UI5 CLI |
Add a fix for properties file encoding when they are part of a build or served such that they can always be interpreted as UTF-8 encoded files.
Read: 0007-properties-file-encoding.mdMerged: 0007-properties-file-encoding.md