-
-
Notifications
You must be signed in to change notification settings - Fork 110
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
fix: Change Editor color customizer label #1051
base: master
Are you sure you want to change the base?
fix: Change Editor color customizer label #1051
Conversation
- Introduce color definition: COLOR_MARK_COMES_FROM_TM_MT - Define it in ColorScheme - Add custom color editor row name in Bundle - Add unit test Signed-off-by: Hiroshi Miura <[email protected]>
waiting review feedbacks |
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.
I just gave this branch a try.
The colour of the segment changes as soon as a fuzzy TM match from tm/mt
is entered (either manually or automatically). However, the colour disappears as soon as I edit the segment or move out of it.
Is that intentional?
I believe I do not change a logic how the Editor gives color, so it has been same behavior as before. My change here is shown on table label in |
@Kazephil Question is answered. Any progress in review in a month? |
Sorry about the delay. I got sidetracked by other stuff and this completely slipped my mind. 🙇 I just looked at it with fresh eyes, and I figured out what seemed odd to me when I first looked at it. I was thinking of the However, for whatever reason, the They get entered as "[fuzzy] translated text" matches when you enter the segment, and highlighted in red. I find it slightly jarring that the highlight disappears as soon as I delete even just the first bracket of "[fuzzy]" rather than only after leaving the segment, but I'm guessing that's part of the original design intent of the MT highlight. Whether these choices are the best would be a matter for a different discussion, so I won't worry about them here. For the purposes of this specific PR, the code does work as intended. I would, however, recommend one minor tweak. Right now, in the Colours table in the preferences, the new "From MT memory" option is all the way at the bottom of the list of colour items, instead of with the other "From memory", "From ICE memory", "From 100% memory", etc. options. The casual user might scroll down to those, see that there is no option to change the MT memory colour, and never actually find the option for MT memory because they wouldn't expect it to be listed separately all the way at the bottom. It would be best if the new "From MT memory" could be listed with the other "From XXX memory" options. (I did try to look at the code to see if I could propose that adjustment myself, but I couldn't quite figure out where the table for the colour options is built or how the options are ordered.) |
On Jul 13, 2024, at 9:14, kazephil ***@***.***> wrote:
I was thinking of the tm/auto and tm/enforce highlights, where the segment keeps its colour even while you're editing it and after you leave the segment.
However, for whatever reason, the tm/mt highlight works differently, and is set to be removed when you leave the segment.
The other difference is that tm/mt matches are not auto-populated even if they are 100% matches.
That's a specificity of tm/auto and tm/enforce references. Other references in tm/ are not autopopulated.
They get entered as "[fuzzy] translated text" matches when you enter the segment, and highlighted in red. I find it slightly jarring that the highlight disappears as soon as I delete even just the first bracket of "[fuzzy]" rather than only after leaving the segment, but I'm guessing that's part of the original design intent of the MT highlight.
The intended behavior (which does not really show here) is that when you modify the mt match, it becomes an edited/validated match and thus is not colored anymore. Only the unmodified matches retain the mt color. And as you describe, only when you enter the segment.
The way I use such references is that I put them in tm/mt/penalty-010 and I have an automatic threshold of 100%, so that they are never automatically entered. That way I don’t have the [fuzzy] prefix and I can see how the coloring is removed after I *really* modify the match.
Whether these choices are the best would be a matter for a different discussion, so I won't worry about them here.
Indeed.
For the purposes of this specific PR, the code does work as intended. I would, however, recommend one minor tweak.
Right now, in the Colours table in the preferences, the new "From MT memory" option is all the way at the bottom of the list of colour items, instead of with the other "From memory", "From ICE memory", "From 100% memory", etc. options. The casual user might scroll down to those, see that there is no option to change the MT memory colour, and never actually find the option for MT memory because they wouldn't expect it to be listed separately all the way at the bottom.
It would be best if the new "From MT memory" could be listed with the other "From XXX memory" options.
I second that.
|
Indeed. I wonder if optionally auto-populating MT matches would be useful feature for people who use the MT feature.
Right. In that respect, the intended behaviour matches the actual behaviour. I just wasn't exactly what I had expected, for lack of familiarity with using MT memories.
Interesting. I like the idea of applying a |
It is the feedback for the change that is an order of the color configuration item.
|
Signed-off-by: Hiroshi Miura <[email protected]>
Now ready to merge. |
Current explanation label of color for translations from tm/mt/* is bad.
This enhance variable name, color name and label.
Pull request type
Which ticket is resolved?
What does this PR change?
Other information