Fix bug 1616918 - Enforce newline at end of Fluent strings when compa… #1574
Conversation
…ring. This solves a detection problem with simple Fluent strings, where the newline is missing from some Fluent string in history. This enforces trailing newlines, making the selector find the correct similar translation.
|
(Unless you want to also fix the Source Editor, then I'll review again) :-) |
|
Yeah, I wanted to fix it because it was actually caused by this. Now it should work in all fluent cases. I've also added a bit more code to fix another issue with unsaved changes (I do it here because I find them as the initial translation is also used in the same translation selector, sorry for the review mess). Note that I can reproduce the unsaved changes issue I talked about locally, not sure why it doesn't happen in the case you linked to. |
There was a problem hiding this comment.
Great work!
I also can't seem to reproduce https://bugzilla.mozilla.org/show_bug.cgi?id=1614590 anymore. Is this expected or a side effect?
| // we want to turn the string into a Fluent message, as that's simpler | ||
| // to handle and less prone to errors. We do the same for each history | ||
| // entry. | ||
| let ftlMessage = fluent.parser.parseEntry(translation); |
There was a problem hiding this comment.
Nit: I don't like that we're using two inconsistent names for the seamingly same concept: ftlMessage and fluentTranslation.
…ring.
This solves a detection problem with simple Fluent strings, where the newline is missing from some Fluent string in history. This enforces trailing newlines, making the selector find the correct similar translation.