Activity for Jean-Christophe Helary
-
Jean-Christophe Helary posted a comment on ticket #1763
How can we go about that ?
-
Tag manipulation
-
Supported file formats
-
add character/word info in the progress bar
-
@t_cordonnier can you point @miurahr9 at your PR so that he can merge ?
-
@miurahr9 I am not seeing this fix in the change.txt file.
-
@miurahr9 could you please take a look when you have some time?
-
[Team project] Github requires access token, not password
-
What you mean is that the autocompletion is incremental: the suggestions appear as the first corresponding characters are typed, and can be partial: you can end the completion at any point within the "autocompleted" string. Is that correct? If that is the case, I don’t see why the feature could not be useful for TM matches also. In which case, you could start typing from any character included in the MT/TM and the completion would start from there, which would be useful for "sub segment" matchin...
-
Is that better than the shortcut access that we have?
-
I would say yes.
-
This was merged in February so it is available in the weekly builds.
-
Have you proposed a PR based on your fix?
-
"avoid logging stack trace" is not a feature request. The feature request is that the user should be able to fix the issue by reading the error message.
-
Specify which filter has a problem in error message
-
Ok, since we’re working on the 6.0.1 bugfix, I guess that label can be considered a bug. So yes, reverting that string is in order. @kosivantsov, sorry for the discussion below. Let’s work on a reasonable implementation of checks after 6.0.1 is released. @msoutopico, did you identifiy other strings to revert?
-
Can't open an OMT package
-
This tracker is for documentation issues (problems in the manual, etc.) If you are looking for user support, please ask the user group. You’ll find it in the "Mailing Lists" tab above. On a side note, you should ask your client how to handle OMT packages. OmegaT does not come with a package system by default.
-
Would you mind registering the 2 functions as 2 separate requests with a reference link to this one?
-
It seems to me that in the current state of affaire, a search/replace within a filter and a negative search are 2 functions that would help a lot and stay in line with the current OmegaT search/filter paradigm.
-
I’m working with macOS 12.7.5 and I’m not seeing this. I do not think macOS has much to do with that though. Can I suggest that you create a new user account on your machine and try to reproduce the issue there? If you can reproduce it there, it is more likely to be a general issue.
-
You could check the issues for your document and include glossary items, based on a glossary list that you make sure contains only specific items.
-
I totally agree with you about limiting the scope to the current segment, in that particular case.
-
That's exactly the reason why we have a checkbox list in the issues checking process. Users are smart enough to change what they check depending on their workflow.
-
What I’d like to know is whether the function was coded before we had all the other checks and then forgotten about, hence the inconsistency that we need to fix, or if it intended to leave them aside, in which case I'd be fine with temporarily reverting the labels. I wrote that bug report because I wanted OmegaT to check for all the issues on leaving the segment and it did not do that.
-
I see. Regarding 1b, I changed the label because I was convinced that the function was checking the issues and not only the tags. For ex, if I select to check the segment for LT errors before leaving the segment, OmegaT should do it. I registered a bug here related to that: https://sourceforge.net/p/omegat/bugs/1158/ The explanations were not sufficient in the bug report, but that's the problem I mentioned. This function should check all the issues and not only the tag issues. Or at least offer a...
-
OmegaT does not check errors when tag errors are not present
-
See here: https://sourceforge.net/p/omegat/bugs/1225/?limit=25#8cc4/2a02/1a77/7acf The check I mention is the automatic check made when leaving a segment.
-
I see. I changed the label because I was convinced that the function was checking the issues and not only the tags. I registered a bug here related to that: https://sourceforge.net/p/omegat/bugs/1158/ The explanations were not sufficient in the bug report, but that's the problem I mentioned. This function should check all the issues and not only the tag issues. Or at least offer a possibility to select the possible checks, like the standard check issues option. So we should keep the label, and fix...
-
@t_cordonnier @msoutopico Can you take care of the new option label ?
-
Adding a toolbar in OmegaT
-
12 years later... What about an optional toolbar, with an arbitrary number of buttons, set by the user, with room for associating an icon or just text to any function declared in the menus? Version 6.2 is supposed to have a focus on UI, so maybe we could brainstorm on what could possibly help users, more than what we did with the 6.0 UI refresh?
-
Thank you Andrea.
-
Losing all progress when using the same language code as source and target
-
Thank you Andrea for the tracker. This item will handle your second point. For the first one, should be registered separately in the Feature request tracker, with a link to this one.
-
Thank you for the reminder.
-
[fuzzy] option in "Check issues"
-
I'm closing because help request should be sent to the user list. But, the wording of the dialog has been modified in the developper's version and you can also use the "flagged text" option to produce the same effect now.
-
We already have action-based script subfolders. Isn’t there a way to use them to achieve that result?
-
The install system has been fix in the master code I think. You may want to try the latest weekly build available from the same github page.
-
Ok. Use './gradlew installDist' instead. OmegaT.jar will be found in build/install.
-
Thank you. Can you indicate the command that you tried?
-
So it might be a difference between Java 8 and Java 11 on your machine. You may want to try OmegaT 5.8: https://github.com/omegat-org/omegat/releases/tag/v5.8.0 You'll need to build the code though. 5.8 is a 6.0 that only requires Java 8. So you'll need to test it with Java 8.
-
Maybe, but M1 has been released a while ago, 6.0 is one year old and even though we don’t have that many mac users, if M1 was the only cause I think we’d have heard about the issue by now. Do you have an intel machine with similar specs around ?
-
Running OmegaT on 12.4 and no issue here with a late 2015 MBP.
-
Especially now that 2fa is becoming the norm, I think obfuscating pw display is totally obsolete.
-
I've tested the branch, it works. I guess that one should go in 6.0.1 too.
-
Create a glossary item with a link ending with a parens (for ex, the link above) in comment click on the link from the glossary pane the closing parens is not taken into acount in the clicked link and that leads to a 404 error
-
I don't suppose that OmegaT is the only application that has such issues with very long password. What I mean is that we should not invent a square wheel when probably existing implementations already solve the issue. If you have time to find how other solutions are implemented and document that here, that would be very helpful.
-
Generally speaking, double-clicking on a continuous string selects the whole string and not the surrounding white space. I think it is more a case of educating users to use the proper tools and processes than us to find ways to accomodate weird practices. If the issue of surrounding white space is an accessibility issue (and that's totally possible since I am not a specialist of accessibility issues) we should check how accessibility best practices handle the problem. But I don't think we should...
-
@miurahr9 would you mind checking this patch for basic issues?
-
https://omegat.readthedocs.io/en/latest/01.ContributingOmegaT/
-
Could you create a patch, of a github branch so that we can test what you have ?
-
I don't think that's what common practice is. We should not try to second guess what the user wants to input.
-
Done. https://sourceforge.net/p/omegat/bugs/1253/
-
Links with ending parens in glossary panes
-
There seems to be still an issue with links that end with parenthesis. https://fr.wikipedia.org/wiki/Doughnut_(modèle_économique) leads to https://fr.wikipedia.org/wiki/Doughnut_%28modèle_économique without the closing parens.
-
Ignoring issues options
-
What about implementing the issues window as a pane ?
-
Sorry I missed that. I'll remove the message on GH. Thank you.
-
Thank you for checking. I think that in the long run, we need to have a locale based shortcuts selection process to avoid conflicts. In the meanwhile, changing the shortcuts is the best option.
-
I mean that your plugin is now just a plugin that people need to install. It might be nice to have that functionality within OmegaT. That means integrating the plugin as code in OmegaT. You may want to check the development documentation for that. You can subscribe to th user list and send your message there. The list is hosted on SourceForge, you'll find a link to it in the "Mailing Lists" tab of this project site.
-
A lot of keyboards do not have R-alt (or even R-Ctrl). I don't think it is a good idea to use R/L as a modifier diferenciator.
-
Having the focus is the original implementation. People are used to work like that. Your issue window is placed where you want to place it. I work with the main window fullscreen and that new implementation makes me waste my time. Because the issue widow does not have the focus I can't even dismiss it with ESC, for ex. I need to use the mouse to activate it. As far as I tested, Thomas patch works very well and seems to also fix the bug that Manuel reported.
-
The bug report does not say that it expects the issue window to not have the focus. Not having the focus is a regression.
-
See, isn't it quite amazing what people can achieve when they decide to scratch their itch ?!? :-) Thank you so much for what you did. Honestly, I think you're just a few steps away from integrating the plugin yourself to OmegaT. And I really encourage you to try to do so. When that is the case, I'm sure you'll have other developers (or me) suggest things here and there so that the new functonality feels "OmegaTish". Let me also suggest you to announce the plugin to the user list. Thank you agai...
-
On macOS, adding cmd to alt modifies alt, but adding ctrl to alt does not modify alt. So, basically, all our alt shortcuts are potentially problematic when using ctrl, i.e. on Windows and Linux... I guess it would be nice to provide a mechanism that offers locale-based shortcuts. In the meanwhile we can ask the translation teams to check with standard locale keyboards if we have problems with the various shortcuts. Also, with the Polish keyboard, Shift Alt D interfers with Ž.
-
There is nothing in the project memory. Which is the reason why this is weird.
-
Notes and Glossary panes keep HTML link styling
-
Here is a new version of the project. With 4 sentences. Each sentence has one exact match in a tmx located in "penalty-010". In segment 1, 2 and 3 the fuzzy in segment_1.tmx appears as a project fuzzy and not as a /tm fuzzy. And thus the penalty is not applied. Even though the fuzzy has not yet entered the project_save.tmx.
-
tm/penalty-nnn value is not respected
-
Here is a new version of the project. With 4 sentences. Each sentence has one exact match in a tmx located in "penalty-010". In segment 1, 2 and 3 the fuzzy in segment_1.tmx appears as a project fuzzy and not as a /tm fuzzy. And thus the penalty is not applied. Even though the fuzzy has not yet entered the project_save.tmx.
-
The same entry in segment_1.tmx generates the 90% match and the 100%.
-
There should not be a 100% match.
-
This is what I get.
-
I think it's OK to have an exclusive choice here, at first. Maybe someday we figure out how to mix the two.
-
We can't use other columns because there are requests to support more than 3 columns (which is common in terminology files) and this would clash with such a feature. The directive could be adding a "neutral" regex (for ex. \r) at the beginning of the source term and adding an opion "support regex in glossaries". With the option enabled \rモータ\d+ would be read as モータ\d+ Similarly \r.+ would be interpreted as .+ etc.
-
Short glossary items are not recognized with Korean source
-
https://github.com/omegat-org/omegat/pull/959
-
Short glossary items are not recognized with Korean source
-
Short glossary items are not recognized with Korean source
-
You don't sound pretentious. You sound like a genuinely interested person who has ideas. That's the reason why we have trackers here. Sometimes, developers come here, pick up an idea and implement it. It is never easy. OmegaT is 20 years old. It is quite a big and very complex piece. I used to be like you :-) "Hey it's easy". Now I know it's not easy :-) Thank you for sharing here and don't go away just because you don't have single click !
-
Ok. So, you are a programer ! Nice to hear, You are welcome to implement a prototype and we’ll see how it goes. Check the development guidelines here: https://omegat.readthedocs.io/en/latest/ Development takes place on github: https://github.com/omegat-org/omegat/
-
I guess we got used to move around the interface with shortcuts. It kind of looks like the modal editing mode vi has. Where in one mode you can do such and such and in another one you can do other things.
-
Ctrl+J and then hit the corresponding letter ?
-
It's not a single operation. It's taking one hand off the keyboard, use a separate device to point at a location, click on that location, put back your hands on the keyboard. Why do you need to use a mouse to change of segment ? Everything is already at your fingertips.
-
You tell me! If Hiroshi and Kos implemented a new behavior that your patch fixes, then let's go with your patch. The current master is a regression.
-
Ok, it looks like the "old" behavior is back. When the automatic check on leaving a segment is enabled, the issue window automatically comes to the forefront with the focus on and can be dismissed with Escape. So, for the particular issue that I mentionned earlier, I guess I can say that it is fixed. Thank you @t_cordonnier.
-
tm/penalty-nnn value is not respected
-
Sorry. I just realized that the /source folder and the file enclosing folder are not the same. The file can be located in sub folder and as such opening the enclosing folder makes sense. So I guess we need to find a proper way to handle this issues.
-
I just checked. It works in 4.1, but in 5.7 it does not seem to work anymore. Since we have direct access to the enclosing folders already, I don't think this function serves any useful purpose.
-
I don't remember what was the state of the interface in 4.1 so I'm not sure what purpose that surved. Now that we have full access to the files and the enclosing folders, I'm not sure it's necessary. Plus, it looks like it does not work. May I suggest that we send a message to the list to see if some people use it?
-
Same.
-
meta 1-5 are reserved to select the fuzzies, so I tried with 9: projectAccessCurrentSourceDocumentMenuItem=meta 9 projectAccessCurrentTargetDocumentMenuItem=meta alt 9 projectAccessWritableGlossaryMenuItem=meta alt shift 9 the 3 work without issue.
-
Here are the settings I'm trying now. And they work fine.
-
It looks like 6.1 behaves properly already. There must have been changes between 4.1 and 6.1, or maybe it is moving from Java 8 to Java 11. In any case, I can't reproduce this bug anymore. I was able to assign: projectAccessCurrentSourceDocumentMenuItem=ctrl alt 1 projectAccessCurrentTargetDocumentMenuItem=meta 1 projectAccessWritableGlossaryMenuItem=meta alt 1 and they work fine. Have you confirmed the faulty behavior on your side?
-
Ok. So you mean that filter specific tags have priority over user defined tags, is that correct? It seems to me that user defined values should have priority oger generic values.
-
Ok. So you mean that filter specific tags have priority over user defined tags, is that correct?
-
Excellent idea.
-
sdlxliff filter does not display (some) comments
1 >