Activity for Jean-Christophe Helary
-
Jean-Christophe Helary posted a comment on ticket #621
That’s weird. Now OmegaT does not seem to allow for glossary items without target terms. Has there been a change in the code ?
-
I guess that is something that we would like to fix, to make sure that the longer command is properly recognized. What do you think?
-
FYI. The PR has been closed.
-
@miurahr9 did you consider this comment of mine in the current implementation?
-
Sorry, it should have been scripts. The folder you mention is an old artifact that was used as a very primitive API to access segment contents. It has no relation whatsoever with what we call "scripts" here. The scripts folder is what we discuss here and it is by default in the application folder. Maybe it is time to rename that old script folder to something more explicit, and keep scripts for the OmegaT distributed scripts.
-
Ok, so, the script folder is in the application folder for any version of OmegaT. Some users know that it can be in the configuration folder and put either all or a part of the scripts in the configuration folder. So the easiest and safest way to solve the issue is to check whether there is a script folder in the configuration folder. If there is none, install the scripts, if there is one, consider that it is user action and do not install anything. What do you think?
-
The "event based action" folders are automatically created since 6.0, which means that pre-6.0 can have a normally populated script folder but without "event based action" folders. In that case, I don’t think overriding with default scripts in the good choice. That indicates a system that is being upgraded from pre-6.0 to 6.0+, in which case I think we should just add the non existing "event based action" folders. What do you think?
-
@msoutopico, are you satisfied with the implementation?
-
Spellchecking still does not work. And there is a new (probably unrelated) error. 13:58:59.614: Info: Évènement : modification du projet - « LOAD » (LOG_INFO_EVENT_PROJECT_CHANGE) 13:58:59.712: Info: Selected LanguageTool source language: ja-JP (LANGUAGE_TOOL_SOURCE) 13:58:59.712: Info: Selected LanguageTool target language: fr (LANGUAGE_TOOL_TARGET) 13:59:00.127: Info: Chargement du glossaire glossary.txt (CT_LOADING_GLOSSARY) 13:59:00.245: Info: 628 entrées de glossaires ajoutées depuis glossary.txt...
-
Thank you Jaime. It is the correct place. I’m not working on Linux, but somebody who does will eventually comment.
-
I just sent your proposal to the user list. Let’s see how it goes.
-
You’re right. That’s pretty much the original setting as it’s been for close to 20 years. The diff function was only added later.
-
We have color settings but I’m not seeing the colors associated to diffed parts.
-
Is this a fix for #1308 ? You mentioned above that the behavior was consistent with the design and that we just needed to relabel the UI.
-
Just out of curiosity, could you make a few screenshots with your proposal and what Trados and others (eventually) look like ?
-
Ok. We can revert to something like "Check tag issues when leaving the segment". Our next issue (and @miurahr9, you mentioned that the other day) is that some language pairs that require tag order changes will always appear in the the issue window. So this function should be limited in scope to the segment, and not to the document or full project.
-
Why do you close as unsupported ?
-
Suggest quality default fonts based on platform
-
I don’t think we should increase the Java requirements without considering which platform we leave behind. Displaying emoji is not a required feature for OmegaT.
-
Modify the CSS for the DocBook 5.0 manual
-
Add tmx prop in the TM match display templates
-
Describe tmx prop display syntax in the manual
-
We can imagine the following behavior at first launch: OmegaT checks if ~/Library/Application Support/OmegaT/scripts exists if it does not exist, OmegaT creates it OmegaT checks the contents compared to its internal contents if internal files are newer than local files, OmegaT asks whether the user wants to: keep the new version keep the old version keep both
-
Externalize the script folder so that macOS users can access it
-
Create better documentation for MT services access
-
No automatic spellchecking in 6.1
-
No automatic spellchecking in 6.0.1
-
To notarize and publish OmegaT 6.0.2 we need to externalize the script folder, like we did for the manual folder.
-
place the souce line of a new segment not higher than the first line of the O.-window
-
If you work with Deepl, you’d better create a segment based TMX with its output and use the TMX from within OmegaT. That would save you a huge lot of work.
-
If you have specific requests like: - make stemming optionnal - display some sort of match % somewhere in the Editor pane feel free to create a RFE. The project that you sent behaves properly and OmegaT does not consider the two segments as equivalent : If you put the first translated segment in a TMX inside /tm/auto OmegaT will not automatically translate the second segment.
-
OmegaT treats as repetitions segments that are not identical
-
When OmegaT inserts a match above the set threshold, it also inserts a marker that indicates that the match was automatically inserted. To confirm that the insertion is valid, the user either manually removes the marker, or uses the "insert match" function to manually insert it. I’m not sure I understand what you mean by "the lack of match percentages in the editor pane". Which percentage should be displayed ?
-
Auto-completion list of glossary terms appears alphabetically even with the relevant setting unchecked
-
Please, make sure that the project opens properly on your side.
-
We need a sample project. We don’t need you to share the original. Just create a source file with two different segments that are considered identical in OmegaT. Put that is a project with a corresponding 1 segment TMX and check that you reproduce the issue before sending it to us. We’ve had OmegaT used in mission critical work for more than 20 years by thousands of professional translators who depend on reliable tools to pay their bills and we’re pretty reactive on bugs that we can reproduce.
-
Alert users if Editor pane is minimized
-
How is that related to the script folder location that we are discussing here ?
-
I can create a new issue, but this one (1781) is good in my opinion.
-
Ticket moved from /p/omegat/bugs/1184/
-
yes. It does looks like related issues.
-
We need a sample project to reproduce the issue.
-
There are no problems. I misunderstood what you wrote above.
-
Good idea. But we can’t remove a feature, so we need to also have the Path in Segment properties.
-
Thank you Hiroshi. Would you mind telling me how to find that information myself so that I don’t depend on you for it? Thank you for the log reference. Ok so we have a UI label that’s not been relevant for 14 years... 😅 That’s obviously an issue. We can’t label the "Comment" pane that way if it also contains stuff that’s not comment. But we can’t have a "Search in comments" if comments are not properly identified and made available. So, it’s not the pane label that is a problem, but the pane contents....
-
Do you agree with my position ? Another solution would be to not put things that are not comments in the pane. Did the pane contain metadata that was not comments from the beginning? I am surprised. (I know how to create a PR. I’ll do that when we reach a conclusion.)
-
I have no understanding of the code. What we need, is that the spellchecker is active in the first segment after the project is loaded.
-
It is not a misunderstanding on how the comments pane works but a mislabelling of the pane. If it contains metadata that is not "comments" it should not be called "comments".
-
It seems to me this one also applies to 6.0
-
Regarding the intended behavior: OmegaT does not validate the xml:lang codes, so anything can be used in this regard, "und" is an acceptable value (although it should be "undefined", to avoid any misunderstanding) we need to warn users that having the same language code in source and target is not acceptable since OmegaT won’t be able to read the contents of project_save.tmx with identical codes. since identical codes keep OmegaT from properly running, the warning should probably force users to change...
-
There is a different issue, where the match appears twice (I’ll open a different tracker later), but the penalty is respected so I consider that the fix is working.
-
@miurahr9 If we notarize the 6.0.2 OmegaT.app package, the OS will not allow anymore modifications to the contents of the OmegaT.app package. Hence, we need to relocate the scripts directory to an external location, as we did for the manual in https://sourceforge.net/p/omegat/feature-requests/1777/. Would you mind checking if you can handle that?
-
Installer to place selected manual in best folder for platform
-
Installer to place selected manual in best folder for platform
-
https://github.com/omegat-org/omegat/pull/1277 is merged
-
One issue described here is still valid : without entering language codes, that project when opened by OmegaT does not trigger alert messages We should have an alert for the lack of codes as I proposed in my comment here: https://github.com/omegat-org/omegat/pull/1604#issuecomment-3173887459
-
But the new filters are not useable because of bugs we found recently.
-
Bundled spellchecking dictionaries are not recognized
-
I am reopening because the situation has not improved with the merge of https://sourceforge.net/p/omegat/bugs/1294/.
-
How is that a duplicate of https://sourceforge.net/p/omegat/bugs/1299/ ?
-
Even though the https://sourceforge.net/p/omegat/bugs/1294/ bug is fixed, I don’t see any improvement to this issue. In fact, now installed spellchecking dictionaries are not even recognized and spellchecking does not work at all (fr). OmegaT-6.1.0_0_37b751991
-
Thank you for your explanations. It seems to me that the behavior happens regardless of the time spent in that segment. Your explanation seem to mean that after the spellchecker thread is "active", spellchecking is working. That does not seem to be the case. It seems to me that option 1 is the best, so we’d need to have an estimate of how longer the load time would be. Would the increased load time depend on the project size ?
-
That is something I had noticed and reported a while ago, but I can’t find the reference. Sorry, I should have been more thorough.
-
Ok. I see. It is not the build process that copies the manuals, obviously, but calling the manual from OmegaT, that unzips a manual from build/install/OmegaT/docs/manuals and puts it into the configuration folder. Thank you. It works. The only limitation to the process is that OmegaT only unzip/copies one language version and not the whole set of zipped docs. It can be a problem when users work in a given locale but prefer a manual in a separate language. It seems to me that it would be preferable...
-
Can you tell me which gradle tasks allows me to deploy the manuals in the configuration folder? The two tasks above do not seem to change anything.
-
Update documentation on team projects
-
There is a new PR that can be merged. https://github.com/omegat-org/omegat/pull/1552
-
Document " Install plugins from remote repository"
-
@miurahr9 the current build does not seem to deploy the manuals in the configuration folder. The docs folder is empty and calling the help loads https://omegat.sourceforge.io/manual-snapshot/ I did ./gradlew manualZips ./gradlew installMacX64Dist What is the expected build process to obtained the result described in https://github.com/omegat-org/omegat/pull/1277 ?
-
https://github.com/omegat-org/omegat/pull/1277#issuecomment-2681655789
-
"Install" page does not appear traslated in Italian website version
-
The CI dependency issue has been fixed. https://github.com/omegat-org/omegat-website/pull/116
-
Missing letter in title page
-
Missing letter in title page
-
https://github.com/omegat-org/omegat/blob/master/src_docs/developer/47.WebsiteProject.md
-
Option to move to segment via single click
-
Option to move to segment via single click
-
https://github.com/omegat-org/omegat/pull/1053
-
Option to move to segment via single click
-
https://github.com/omegat-org/omegat/pull/1053
-
Option to move to segment via single click
-
Convert OmegaT.vpp to a freely useable format.
-
"The project could not be loaded"
-
Don’t worry Laurent. Take good care of you. Since we can’t have more data on this issue and are unable to fix it, I’m closing it.
-
Misspelled word in the segment opened at launch are not recognized
-
Misspelled word in the segment opened at launch are not recognized
-
Bundled spellchecking dictionaries are not recognized
-
No need to reload a project for spellchecking
-
This takes place after a reload too.
-
No need to reload a project for spellchecking
-
NPE at program exit after b077e93a3
-
Same here: https://sourceforge.net/p/omegat/mailman/message/59191160/ @miurahr9 could you look into this?
-
@t_cordonnier, do you have blockers on the issue ? https://github.com/omegat-org/omegat/pull/1254
-
I’m not sure a json output would be of much use to normal translators. The current json output is in addition to what we have. It does not add extra data. It’s reasonable to add a "add context-bound matches" to a preference somewhere in the UI, which would break the current table layout, but that’s OK since it is a user decision.
-
Oliver, @miurahr9 has implemented something here: https://github.com/omegat-org/omegat/pull/1053#event-18016156979
-
It would be nice to select one term to refer to such matches: context-bound? ICE? 101%? "alternative" (I’m not sure I understand why this term is used here)? I had a discussion in the past with Aaron about modifying the output structure of the statistics function that we had and he opposed it because that would break processes that rely on the current structure. Although I understand that, we must find a way to adapt the output to our needs, which could mean adding a configuration/template system....
-
Please go ahead. @miurahr9 I’ll forward the log to you when I get it.
-
An empty project_save.tmx is created by default. If you have not opened the new project and worked on it, the file does not contain translated segments and it is safe to replace it with the old file. Your input is also precious because it helps us understand what is difficult to understand in the manual. Do not hesitate to create a "documentation" tracker item here to register documentation issues with the manual.
-
2. - The source files are the files in /source. - The reference TMs are the files in /tm - The glossary files are the files in /glossary 3. The most recent file can be corrupted and contain less info than the biggest file. You need to check. Generally speaking, the latest memory is the biggest, and if that’s the case, that’s the memory you need to copy. 4. That’s correct. 5. No. Step 2 was for /source, /tm, /glossary items. The project_save.tmx file is copied in step 5 (as far as the our introduction...
-
fichiers source, fichiers de mémoire de traduction de référence, fichiers de glossaire
1 >
