It might be worthwhile to look into what actually depends on the current output. There may be a way to add this functionality without introducing another preference and without breaking anything. From the user’s perspective, the change likely wouldn’t be very disruptive, since it would still be possible to combine the number of context-bound matches with the other exact matches to get the total currently reported as exact matches. Alternatively, the table could remain unchanged, but the numbers for...
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)? Totally agree, and I’m sorry if it was confusing. My intention was to ensure clarity around the concept being discussed, especially since the CAT tool industry uses several terms for what is essentially the same type of match. But perhaps I should have stuck to one term, listing instead its synonyms or similar concepts in one place only once....
Separate Statistics for Context-Bound (ICE/101%) and Exact (100%) Matches
The same issue as Manuel describes is observed with post-processing commands. Committing and pushing generated target files doesn't wait for the post-processing command to finish.
Another option is to self-sign OmegaT.app you download: Create a Self-Signed Certificate: Open Keychain Access on your Mac. From the Keychain Access menu, go to Certificate Assistant > Create a Certificate. Name your certificate (e.g., My App Signing Certificate), set the Identity Type to Self-Signed Root, and the Certificate Type to Code Signing. Save the certificate in the login keychain. Sign OmegaT.app: Open Terminal and use the codesign command to sign your app with the certificate you created....
I can confirm this started to happen after the macOS 15.1 update. A workaround is to start OmegaT from terminal: /Applications/OmegaT.app/Contents/MacOS/OmegaT, but one will need to keep the terminal window open while OmegaT runs.
Block creation of target files only if the SELECTED issues are found
FYI There was a plugin that did something like that. It split the source into sub-segments, got those sub-segments MT'ed (service selection for the plugin was separate from the main MT services selection), and provided the fetched results as auto-completion suggestions. https://github.com/transducens/Forecat-OmegaT The plugin worked in OmegaT 5.x
It would still be very helpful it the user choices were temporarily disabled when Check Issues is triggered by the tag validation when leaving a segment or when creating target documents. If all issues need to be checked when leaving a segment, then the Check Issues function needs to have another scope: current segment (three scopes altogether: entire project, current document, current segment), and that one-segment scope should be used. Tag validation triggered during file generations shouldn't...
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. When it was added, we had only tag validation. Everything else was (and still is) available in the QA script. Then tag validation was retired and superseded by the Check Issues which is designed to be extendable by scripts and plugins....
I think the more consistent behavior would be for this option to be renamed to reflect that it deals with tags (its intention is rather obvious from the code). And then this option and the option in the Preferences > Tag Processing that prevents creating target documents with tag issues should temporarily disable any other checks selected in the Check Issues and cover only tags. Both of these options are about files validity, not about QA.
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. If this option really checked for all (selected) issues, it would be slow and inefficient. I think the main purpose of both this option in the Editor section, and "Allow translated tags to be in a different order" + "Block the creation of translated files with tag issues" in the the Tag Processing section is to ensure the validity...
Let user decide the maximum number of TM matches displayed
Pali stemming
Dear Dhammanissita, Please refer to the User's Guide (https://omegat.sourceforge.io/manual-standard/en/chapter.dialogs.preferences.html#dialog.preferences.spellchecker). OmegaT tracker is not the place to get user support. To find a suitable support channel, please see http://omegat.org/support Since there is a Hunspell dictionary for Pali, I'm closing this ticket as invalid.
Just to split some hairs here, Linux is not a Unix variant, but a Unix-like OS. And there are certified Unix systems where xdg-open wouldn't be available or would be very limited, like OpenVMS, zOS or Darwin. It's not Unix that you're interested in, but Java running on top of X11, so maybe instead of isUNIX call it isX11?
Random selection of match for pre-translation depending on TMX file paths
Moving to a segment is done far more often (at least for me) than anything else except for typing. There's Ctrl+U to go to the next untranslated segment, and when you press Enter or Tab (whatever is selected in prefs), you go to the segment right after the current. There's also Ctrl+N/P to go to the next/previous segment. While you're translating, clicking to move to a new segment seems like a rather inefficient practice. You're typing anyway, why taking your hands off from the keyboard just to resume...
If this is implemented, it's going to be confusing as hell. You won't be able select text in another segment because it will immediately activate it, regardless how complete your work was in the segment that you were working on.
@kosivantsov could you tell us your opinition whether this can be enabled in default? I am fine either way as long as the option is there.
MT engine error (Google Translate (without API)) begin 9, end -1, length 45
This is not related to OmegaT itself. The bug is in the plugin. I'm closing as invalid
Currently, "locking" the segment boils down to placing a TMX with the identical source to /tm/enforce. So it makes sense that unlocking it would entail doing the opposite, i.e. removing the TMX file from /tm/enforce
Not showing enforced segments could be a hindrance in projects that use TMX's from previous projects, but are not fully translated yet. Either discarding any editions to such segments or setting them to be read-only seems to be a better solution.
Block creation of target files only if the SELECTED issues are found
Here's the related RFE: https://sourceforge.net/p/omegat/feature-requests/1286/
Closing a new project does not register pre-populated translations
You may try my unofficial repack of OmegaT.app that includes so called Fat binaries of the OmegaT launcher and JRE, so it runs natively on both x64 and arm64: https://drive.google.com/file/d/1NR-9_MUgaxmqRcAcss6wLhG3lZCy5C2W/view?usp=drive_link
I sometimes got that when running OmegaT.app with Rosetta (and it's the case with the app we released), but it was sporadic, not constant, as if some key combination disabled the Option key in OmegaT. To work around it, install aarch64 Java and run OmegaT by java -jar OmegaT.jar
I guess, further possible improvement requests should be done in a separate RFE. Is it right?
If this fix is implemented, it should be backported to 5.8/6.0
Yandex translator keeps giving an 403 error
That's different, and that one works. Contact Yandex if you need further assistance with Yandex.Cloud. Your Yandex Translate API key can't be used with Yandex.Cloud.
5.4.0 was released on 12.12.2020, Yandex had already deprecated their older version of the API by that time, OmegaT simply reflected the actual state of things. The latest version for macOS is 5.7.1 (Intel)
Anyway, if yandex is deprecated, why is it still integrated in the base version of the app? Yandex Translate has been removed in 5.4.0
Did you submit any politically incorrect requests? Did your submitted source text contain any information about the Bunker Grandfather or the war Russian Federation is waging against a sovereign nation? Such requests are automatically blocked by Yandex. Besides, Yandex.Translator is deprecated and removed from the latest OmegaT. Therefore I'm closing as invalid.
Did you submit any politically incorrect requests? Did your submitted source text contain any information about the Bunker Grandfather or the war Russian Federation is waging again an a sovereign nation? Such requests are automatically blocked by Yandex. Besides, Yandex.Translator is deprecated and removed from the latest OmegaT. Therefore I'm closing as invalid.
Yandex translator keeps giving an 403 error
Did you submit any politically incorrect requests? Did your submitted source text contain any information about the Bunker Grandfather or the war Russian Federation is waging again an a sovereign nation? Such requests are automatically blocked by Yandex. Beside, Yandex.Translator is deprecated and removed from the latest OmegaT. Therefore I'm closing as invalid.
One place where the tags are actually removed is the Aligner. Now the checkbox there says "Hide tags", but if that option is selected, no tags are presented to the user and no tags are written to the TMX. -- Kos On Mon, Feb 27, 2023 at 11:26 PM Jean-Christophe Helary brandelune@users.sourceforge.net wrote: If the tags are not present in the segment and put back in the target they have effectively been hidden from the user (temporarily removing is hidding). "Removing" would mean that the tags cannot...
RFE: handling ID-bound alternative translations more efficiently
If I remember correctly, the thing to validate tags used to produce an html page with links to the corresponding segments. The bundled QA script produces buttons to jump to segments too. I guess it is possible to create similar links or buttons to recent projects. When I open LibreOffice, it opens the list of recent files (you can configure it to either start a blank Writer, Calc etc. document, or open that thing that shows recent documents and where you can create a new file in any of the available...
The old Yandex connector has been removed, but now we have a new connector for Yandex Cloud which doesn't require a warning about its availability (it might require a warning about Yandex being a Russian-based and FSB(KGB)-monitored service, but it's a different topic altogether). -- Kos
Yes, my statement contradicts Manuel's comments a bit, but it still remains true. Suppose you have an empty folder with only omegat.project in it, and that omegat.project has a repositories section with at least one mapping to a remote repo that contains omegat.project. When you open that folder in OmegaT GUI, OmegaT will create all the project folders even if the remote repo contains only omegat.project and nothing else, and the project will open just fine (the fact that it might be empty is beyond...
What Manuel requests or asks about makes a lot of sense. You can have a repository that originally contains only omegat.project(committed by your git client, or through the web interface, or in whatever other way, it doens't matter), and when such project is downloaded in OmegaT through GUI, the project opens just fine. OmegaT downloads the project file and created everything else that is needed for the project. At some point you can delete some of the local folders (like target or dictionaries),...
What Manuel requests or asks about makes a lot of sense. You can have a repository that originally contains only omegat.project(committed by your git client, or through the web interface, or in whatever other way, it doens't matter), and when such project is downloaded in OmegaT through GUI, the project opens just fine. OmegaT downloads the project file and created everything else that is needed for the project. At some point you can delete some of the local folders (like target or dictionaries),...
Once it's documented in changes.txt, this RFE can be changed to open-fixed
With the new sorting the list is next to unusable: when I select a filter and click "Edit" or "Options", it opens settings or options for the filter that used to sit in that place of the currently selected filter (see the screenshot attached).
Implemented in [6c7b8f] and [1a15c4]. I'm not sure if it requires to be covered in the docs, it improves on the existing functionality without introducing any tangible user-facing changes. I think this one can be changed to open-fixed.
Reuse credentials in team projects
Thomas, please document this implementation in changes.txt, then we could mark it as open-fixed for now, and closed-fixed after the release.
Reuse credentials in team projects
With your proposal we have: C-Q / Enter = Cancel Quit C-Q / mouse = Quit macOS does not have a way to access OK with a key. C-Q / Tab / Space = Quit no mouse needed even on Mac
With your proposal we have: C-Q / Enter = Cancel Quit C-Q / mouse = Quit macOS does not have a way to access OK with a key. C-Q / Tab / Space = Quit, no mouse needed even on Mac
MT cache cleared on saving or committing translation to memory
https://sourceforge.net/p/omegat/wiki/Advanced%20Searches/ See Search in both source and target language with one expression
History completion/prediction is already available, but completing from a dictionary would possibly produce a lot of noise and be counterproductive, or at least it should be given the lowest priority and pop up only if there's nothing from the history.
History completion/prediction is already available, but completing from a dictionary would possibly produce a lot of noise and be counterproductive, or at least it should be given the lowest priority and pop up only if there's nothing in the history available.
The way OmegaT commits segments, it won't be very easy to do. There's always a way to kill OmegaT which amounts to the same thing – closing without saving. If we had a way to undo changes in the committed segments, maybe it would address the main issue behind this request. I'll try to find undo-related issues and link them here.
It's already available: Edit -> Remove Translation (an arbitrary shortcut can be assigned).
Should be closed, it's a L10n nightmare!!!
This one should be closed. One can already select different text colors for different items, but use the same background or specify a different background only for a subset of items.
I'm not sure about Ctrl+J part to jump between segments (it's available both in the Editor and in the Search), but I think (Shift)+Ctrl+I/R could be implemented in the Search window to insert the current search result's source or target into the segment which is currently active in the editor. This might work funny if the Search window is synced with the Editor, but if these functions are implemented, perhaps they could be disabled when the Sync checkbox is ticked.
Ampersands in the context menu
OmegaT could check the available screen geometry, and if its previous position is outside of the available space, its upper left corner could be placed at 0,0 or whatever the upper left corner coordinates are. This way the title bar is visible, Windows users could right-click on the title bar to maximize or resize the window, Mac users will have their left-side window buttons (and all the options on Linux are too numerous to list here).
I'm not sure this RFE is really feasible. OmegaT can be properly installed or used without installation in several different ways. And if it's used without installation, it wouldn't register file type associations etc. Users may choose to have several versions of OmegaT available simultaneously. At the same time, changing the visual representation of a folder is a very OS-specific or even filemanager-specific thing. So should OmegaT add a number of small files to the project folder with the metainfo,...
I just checked the attached text project. Doesn't seem to be the case anymore. Multilingual TMX issues have been addressed on several occasions, and now, while Russian matches do show in this NL-EN project, they don't automatically populate the segments. This one should be closed as either out-of-date or fixed.
[#1565] includes a discussion of a somewhat related issue where in-file segment numbers should/might be used.
Since we have Ctrl+Shift+F that reuses the last Search window, it's now possible to perform searches without opening other windows. Is this RFE still relevant? It looks like it deserves the closed-out-of-date status
I don't see how it's an OmegaT RFE/issue. To make sure that the same tab is reused, something needs to be done on the side of the browser (in Firefox you can pin a tab, for instance, and all further links from that domain will open in the pinned tab). I would suggest to close this RFE as invalid.
BE, CA, CO, DE, PT_BR, UK, ZH_CN l10n updated (UI for all 7, readme – exept PT_BR)
It's possible to get keys for Yandex.Cloud which is different from Yandex Translate. Yandex Translate seems to still be working if you have a valid key, but it has already been removed from OmegaT. A plugin is available here: https://github.com/kosivantsov/omegat-plugin-mt-Yandex.Translate
Dutch l10n updated to 5.8 (UI)
Navigate between segments inserted from /tm/auto and /tm/enforce
Document #1641 (goto-x) in changes.txt
Good to know. I use it all the time. -- Kos On Mon, Dec 12, 2022 at 5:41 AM Jean-Christophe Helary brandelune@users.sourceforge.net wrote: FYI, I've been using it for a few days and it's extremely convenient. Thank you ! [feature-requests:#1639] Add a shortcut to select all source text of the current segment Status: open-fixed Group: 5.8 Created: Wed Oct 19, 2022 02:37 PM UTC by Kos Ivantsov Last Updated: Sun Dec 11, 2022 02:54 PM UTC Owner: Kos Ivantsov While it's possible to unlock the cursor/text...
Update changes.txt (#1639 Select all source text)
Add a shortcut to select all source text of the current segment
Implemented as of [67bf35].
Merge or Split Segments
Good catch, Hiroshi! I haven't seen this behavior for a long time, and I agree that it should be closed.
Fix erroneous double spaces in Bundle.properties
Fix "flagged text" string inconsistency in Bundle.properties (COLOR_REMOVETEXT_TARGET).
Fix a typo in Bundle.properties (OpenXML_TRANSLATE_LINKS)
Fix typo in Bundle.properties (MW_OPTIONSMENU_ACCESS_CONFIG_DIR)
Remove extra spaces in TF_INTRO_EMPTYPROJECT
Fix mnemonics in Project Properties, Local Segmentation Rules and Local File Filters. Fix wording in TF_INTRO_EMPTYPROJECT
Fix a few capitalization errors done in the prev. commit
Consistant sentance case/capitalization in dialog windows
Applied most changes to Bundle.properties from PR 331
Fix mnemonics in Edit menu
Fix mnemonics in Main menu and Source Files (Project Files) list
Fix a typo in name (readme.txt)
More consistent wording for post-processing commands
Fix a typo in Bundle.properties (TMXR_WARNING_SOURCE_NOT_FOUND)
Add unique mnemonics for Project menu (only MED project items w/o mnemonics)
Add several comments for localizers in Bundle.properties
Fix a line break in Bundle.properties in COMMAND_LINE_HELP
Fix a typo in Bundle.properties