-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
weblate & icu format #2856
Comments
Thank you @nijel |
Probably because this is not a valid angularjs format string, we don't have support for ICU syntax right now. |
sorry to insist but our json value string is well an angularjs format string Plural Syntax extract from https://docs.angularjs.org/guide/i18n#plural-syntax our string is {{number, plural, =0{none} =1{(# device)} other{(# devices)}}} and as you see in capture screen, no plural was detected, have i missed something ? thx for your help |
Yes, but I can still repeat: this is currently not supported. What is supported is AngularJS interpolation string |
Hello @nijel , |
The existing AngularJS check is here: https://github.com/WeblateOrg/weblate/blob/master/weblate/checks/angularjs.py This would deserve separate check with flag to enable it. |
What about reusing editor from https://format-message.github.io/icu-message-format-for-translators/editor.html ? |
@nijel Is this the best issue to watch for checking for the supports? Or would be #2967 better? I started using Weblate for ARB files in Flutter and it uses the ICU format as the only option for plurals. #2967 makes it sound like a non-trivial implementation. |
You can watch either. To big extent these are duplicates... Some editor being capabale of syntax highlighting and linting should land as part of #4094, we can then start building the feature on top of that. |
Is there any update to the progress of this? New to the platform however we are already heading deep into ICU/MessageFormat land |
I don't think there has been any progress on ICU format support. Weblate is now using Prism for highlighting in the editor, adding ICU format to that should not be hard and could be a good starting point. |
Hello, I've been looking at using Weblate for the FrankerFaceZ project (browser extension for Twitch) and, as a result, getting ICU MessageFormat working within Weblate. At this time, the Prism support for the format still hasn't landed in a release on npm, but it works to at least a basic level after pulling in the script from GitHub directly. To that end, I've ended up:
Specifically, I've added special logic that changes how placeables work. Rather than being a root element, I moved them into the argument part of the highlighter as the name by itself doesn't matter and including the I ended up not entirely satisfied with how that works out, though. I find it's easy to make a mistake when typing messages like that, especially if escaped characters are involved. To that end, I've looked into a proper parser that can live in the page and give live and direct feedback. In the end, I ended up re-implementing the Online ICU Message Editor within the translation page. It indicates errors and allows translators to test strings with different values in real time. It's very hacky at this point, but before attempting any sort of polish I thought I should reach out and see what other people think. In order to accomplish this editor I have:
Having said all that, here are a pair of screenshots. One showing an error state and one not: Let me emphasize again that this is a hacky implementation, currently only present in the front-end with no back-end checks, and I'm posting to ask about what people think of it. As I'm looking at it now, I'm not sure if I'd prefer the live preview to be better integrated into the existing panel or not. It should also likely be made generic so that any other formats in the future can take advantage of it, such as Fluent. I'm also thinking that it might be better to not use Prism for highlighting these messages and instead do it manually if we're already parsing them into an AST for the preview and error checking. This post is getting too long, though, so please let me know what you think of this direction. The code so far is at https://github.com/SirStendec/weblate/tree/icu-message-format if you want to see it but I shall emphasize again that this is still basically a big hack and not necessarily well structured or following code conventions. Thanks. |
Should probably go to
Looks good. I think having it in the bottom tabs as "Live preview" is the best location. It will allow extending this to other formats as well.
Prism is already used for highlighting other content from Weblate (like whitespace), so better to stick with it. |
A separate file definitely seems like the best route to me, since only a couple of flags will trigger the behavior.
Ah, yeah. I wasn't thinking about the whitespace highlighting and such. Prism it is. To give a general update, I have spent some time to familiarize myself more with how the server application works and I've been implementing checks there. That also involved writing a parser for ICU messages in Python, as the previously mentioned parser pyseeyou has issues. I effectively ported the parser from https://github.com/format-message/format-message to Python, with a couple tweaks to allow it to be a bit more permissive. Notably, format-message doesn't allow spaces in placeholder formats while they are valid as far as I can tell by the ICU spec. That new library is located at https://github.com/SirStendec/pyicumessageformat I have ended up implementing two separate check flags. Currently, all the checks are in one big class, and it handles:
I suppose it should be branched out to multiple classes, but I'm not sure the best way to handle that. On the front-end side of things, I've:
That's the editor in its current state looking at an If your string has an error, the Live Preview panel gets the The code behind all of this is sitting in https://github.com/SirStendec/weblate/tree/icu-checks currently, but I don't think it's ready for a pull request yet. I also want to more thoroughly test everything. I've written a few tests so far, but nothing exhaustive yet. |
Since yesterday, I have:
I'm still not satisfied with how the JavaScript for Live Preview is laid out, but it works well enough for now. Ideally, there'd be a proper place in the source tree for JS that gets run through build tools and a JS test runner. Depending on what feedback I get on all the checks being in one class, I think this might be ready for an initial pull request? |
Yes, that would be great, but a bit out of scope here. But contributions in this area are definitely welcome ;-). Right now, there is a custom build used for third-party code, see https://docs.weblate.org/en/latest/contributing/frontend.html
Having it all in a single class is okay. In the past, the checks had to be more fine-grained as they could not provide additional feedback to the user, but with the current API, it makes more sense to have a single check that would tell what is wrong in the description. |
Alright, sounds good to me. I've been adding a few extra things that I thought of while setting up my project's new i18n pipeline. On the server side of things I've got:
For Live Preview specifically, I was thinking about helping to pre-populate the fields with example values for translators and I came up with the idea of an I'm just wondering how much sense this makes to other people. My own i18n layer detects new/changed strings at runtime during development and automatically captures placeholder values, so I can easily dump sample data in for every unit. I also haven't looked into that backend that hard, so I'm not clear about, for example, the maximum length of a flag string and if storing some JSON would present an issue there. Also, I want to improve highlight extraction so it stops grabbing entire placeholders with sub-messages. It should definitely not pull in anything with sub-messages. Just haven't gotten around to that yet. Been a bit busy with other work projects. |
I'm not sure about using JSON here - it is easy to get it wrong when editing manually. But I don't see a better choice here... The length is not an issue for flags. |
Hi @SirStendec, Do you have any progress with this? Do you need any help? |
Hi @orangesunny, I ended up busy with some other projects so I had to put this on hold for a bit. I should be able to finish things up soon. I am basically done with what I wanted to accomplish, though I'm not entirely happy with the Live Preview that is mostly to do with how JavaScript assets are structured in weblate. The code in https://github.com/SirStendec/weblate/tree/icu-checks is current with my copy, so you can grab that if you want to test it yourself. It's probably ready for a PR, but ideally I'd like some more ICU formatted strings from other projects to test it with to help make sure everything's working well and that there's no weird input case I'm not handling or catching with unit tests. |
There are definitely better ways to do that, but somebody with the expertise would have to redesign this and so far, most contributions to Weblate comes from the backend devs... The current status is documented at https://docs.weblate.org/en/latest/contributing/frontend.html Anyway, you are welcome to open a pull request to get a review of that code. |
I was able to better test the ICU checks recently thanks to another project that has just over 350,000 strings. (My own project is only around 10,000.) As such, I'm feeling much more confident about the state of the server-side code and I'll be putting in a pull request for that soon. Possibly tomorrow if my schedule remains clear. The Live Preview feature will be coming in a second pull request at a later time. I've got a good general idea how I want to handle its internals now... because I went ahead and implemented support for Fluent into it as well, in celebration of beta support for Fluent documents landing in Weblate. Having two supported formats makes it more obvious where the shortcomings are. |
Eagerly awaiting this PR for many years. I can also offer some testing but I don't have a lot of strings atm to test with. |
Thank you for your report; the issue you have reported has just been fixed.
|
Hi, Sorry for the bump of a closed issue, but I would like to know if the LivePreview component is always on your sight @SirStendec? :) It's exactly what we are looking for the manage translations of ours projects with Symfony. If you need help, don't hesitate to ask! |
Same here, the Live Preview feature is a game changer! |
Is your feature request related to a problem? Please describe.
Hello ! I would like to colorize the part of the text to be translated by translators because they are not able to know what should be translated
(e.g. {number, plural, =1{(# device)} other{(# devices)}} The translators had only to translate "device" and "devices" so I want thes two words to be colorized)
The text was updated successfully, but these errors were encountered: