Philippe

That looks like a screenshot from a pre-6.0 version. The current one, even in German has a different message. The English message, by the way is: Specific sets should be put above general sets: "FR-CA" should be above "FR.", which should be above ".". All sets that match the project source language are applied. The message itself might still benefit from having "For example, " added before the sentence describing how more specific language codes should be placed before less specific ones, and maybe...

Strangely, I've only gotten a dialog box with an error on my work system (Windows 11, either Professional or Enterprise). On my Linux and personal Windows 11 (Home) system, I don't get an error message, but the error does come up in the log. I haven't gotten the same type of errors Jean-Christophe did, but I did get characters getting inserted to the left of the previous character (so I get "ehT" if I try to type "The") the first time I start OmegaT. This problem usually fixes itself if I close OmegaT...

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...