Philippe

How would this be better for you than Ctrl+Jand either the shortcut letter or segment number? (Or right-clicking and selecting Go to Segment, for that matter?)

If we're okay with leaving the message in English, maybe a key in OConsts.java for the message in line 735 of RealProject.java? Conceptually, I like the idea of having commit messages in the target language, but are there enough messages to make it worth the time and effort required not only of the code developer, but also the localizers?

Tricky question. Ideally, enforced segments should be locked to prevent editing, but… …a means of unlocking an individual segment to edit it if it contains an error should also be provided, and this would require saving the edited segment in both project_save and the enforced tm, and then re-locking it. That second part may not be trivial to implement, especially since OmegaT does not distinguish between "edited" and "confirmed" segments. (Then again, it may not be necessary to implement both parts...

Hiroshi's comment on the differences in the filters.xml configuration made me realize I had reused a configuration created with a pre-6.x version of OmegaT. (The Okapi filters shouldn't be in my test configurations for 6.x). I tried again with both 6.0 and 6.1 (latest master), with the same results in both: * If I only enable MsOfficeFileFilter, OmegaT does not see the Excel file in the /source subdirectory. * If I enable OpenXMLFilter in addition to MsOfficeFileFilter, the file loads with the legacy...

It does seem to be an issue with the filters file. If I replace my original filters.xml file with Didier's and try to load my test project with the latests OmegaT master (90625acc2), OmegaT tells me there are no source files in the project. If I close OmegaT and replace Didier's file with my initial filters.xmlfile, everything works again. I'm attaching my own file for reference. (Note that it was originally created (by OmegaT) in 2021.) Interestingly, if I replace Didier's file with mine without...

"Curiouser and curiouser, said Alice" Can you test your project with a fresh, empty configuration directory? Steps: 1. Create a new directory to hold the OmegaT configuration in any convenient location. You can call it anything, but for example's sake: mkdir ~/.omegat-test 2. Run OmegaT with the --config-dir parameter: (path/to/)java -jar -Xm4096M omegat.jar -config-dir=~/.omegat-test 3. Open your project (Use the full path for for the correct java executable if necessary, and feel free to change...

Twice 4096 would allow the Java virtual machine to use all of your system's RAM (more than that, actually, since some of the 8GB is used by the system itself), so it might lead to heavy use of swap and affect the system or other applications if OmegaT ends up grabbing all of that memory in the JVM. I'm not sure exactly how memory is managed or allocated in Linux, but I think it is primarily handled at the kernel level, but there a probably a bunch of other factors at play as well. Out of curiosity,...

I think Jean-Christophe is on the right track about a memory issue. How much memory is allocated for OmegaT to use? The default installation only allocates 1GB, which will not be enough. Try editing the -Xmx1024M portion of the command you use to launch OmegaT, increase it to, say, -Xmx4096M and see if that helps.