Activity for Briac Pilpré
-
Briac Pilpré posted a comment on ticket #1213
Can be fixed by https://github.com/omegat-org/omegat/pull/726
-
Generate JSON format stastics file when save
-
Generate JSON format stastics file when save
-
Implemented in [d00d63]
-
The defaults in the proposed PR are Text and JSON
-
Content of notes elements are not displayed correctly with XLiff filter
-
Output statistics to text, xml or json: PR https://github.com/omegat-org/omegat/pull/675
-
Content of notes elements are not displayed correctly with XLiff filter
-
Fixed in [368c58] Backported to 5.8.x in [7e8df6] Backported to 6.0.x in [d3034a]
-
Content of notes elements are not displayed correctly with XLiff filter
-
OmegaT uses wrong/old version of plugin in case of conflict
-
Fixed in [47c917]
-
Search results no longer distinguish the source of the result, e.g. which TM.
-
If the checkbox "Display: file names" is checked, it should indicate where a TM match comes from.
-
PR: https://github.com/omegat-org/omegat/pull/646
-
Thanks Hiroshi, I wasn't aware of this new button and feature, that's great! My thinking was more for the cases when several versions of a plugin are already installed on the filesystem, and/or when a user install plugins manually without the help of the GUI.
-
Currently ([9ecbf5]) the plugin loading done in org.omegat.filters2.master.PluginUtils.loadPlugins(Map<String, String>) does not do anything regarding the different plugin versions located in the plugins folder. If it contains a proper Manifest, we try to load the plugin. Since it's difficult to unload a class from the Classloader, subsequent versions of the same plugin won't be taken into account. One solution would be to make a first loop that read all the Manifests from the jar before loading...
-
Translation memories are not correctly reloaded after team synchronization
-
External memories are not correctly reloaded after team synchronization
-
The COMPILE event is fired *after* the target commit
-
Closed by [296a0a]
-
PR: https://github.com/omegat-org/omegat/pull/609
-
Default filters settings don't initialize options
-
Error when trying to backup the project file on Windows
-
This bug is reproducible on a minimal team project: https://github.com/briacp/omegat-team-project.git: 1. Open/Download the project 2. Go to the first segment 3. Ctrl+S to force project synchronization 4. Enter to move to second segment I think this happens during of the call to projectTMX.replaceContent(newTMX) inside RealProject.rebaseAndCommitProject(boolean). The defaults/alternative TM are reset before the updated TM from the remote server are read again, which in turn gives an empty result...
-
Fixed in PR #554
-
Project not loaded if it contains DTD internal entities
-
"Set empty translation" does not work in XML file
-
The problem lies in the Okapi filter, it only allows empty translations for bilingual files (e.g XLIFF). Since your file is plain XML, every empty translation is replaced by the source text. I'm not sure how it can be fixed without introducing unwanted behaviours for existing projects that rely on this. Maybe add a new option in the Okapi filters to explicitly allow empty translations (but I'm not sure we can distinguish between "real empty" and untranslated on Okapi side. See : * Okapi omegat-plugin...
-
Project not loaded if it contains DTD internal entities
-
Entities are not
-
chore: update changes.txt with bugs 1154
-
Searches on "reference TMs" are not properly labeled in the search results
-
Fixed in [031aef]
-
Don't display preamble line in search results if no filename set
-
Thanks, the "null" preamble is present when the filenames are unchecked. I think the correct behavior is to remove the preamble (filename and "+ X more") when the filename checkbox is unchecked, this would lead to these kind of results: All Matches and File names : All Matches and no File names : No all matches and no File names : No all matches and File names:
-
Thanks, the "null" preamble is present when the filenames are unchecked. I think the correct behavior is to remove the preamble (filename and "+ X more") when the filename checkbox is unchecked, this would lead to these kind of results: All Matches and File names : All Matches and no File names : No all matches and no File names : No all matches and File names:
-
Thanks, the "null" preamble is present when the filenames are unchecked. I think the correct behavior is to remove the preamble (filename and "+ X more") when the filename checkbox is unchecked, this would lead to these kind of results: All Matches and File names : All Matches and no File names : No all matches and no File names : No all matches and File names:
-
Do you still have the error? I can't reproduce the bug with the latest 5.8.0 [972368] on the FR i10n project (or maybe the search options are not correctly set)
-
fix: minor fixes for #1683
-
Duplicate file `docs/XX/omegat.css` on windows
-
Wrap long text in message dialogs
-
style: remove unused imports
-
fix: forgot to refactor a call to isFromMTMemory
-
style: spotlessChangedApply
-
fix: Color the fuzzy matches from /tm/mt
-
fix in https://github.com/omegat-org/omegat/pull/496
-
This issue is not directly OmegaT, all the transformations are done in the Okapi filter. As a matter of fact, this filter is explicitly replacing the source with the protected translation (the tooltip still show the original source text though). See the ticket omegat-plugin#2 discussing the issue.
-
This issue is not directly OmegaT, all the transformations are done in the Okapi filter. As a matter of fact, this filter is explicitly replacing the source with the protected translation. See the ticket omegat-plugin#2 discussing the issue.
-
FWIW, I'm all for integrating this in core OmT the way Thomas proposed.
-
Well, if that's the case, I'm all for renaming both properties to something more precise of what the property is supposed to do!
-
Refactoring the confusing `removeTags` properties
-
Refactoring the confusing `removeTags` properties
-
fix: display project properties dialog title
-
Matches containing non-alphabetical text are ignored in TM leverage
-
I noticed my fix introduced a not-so-subtle bug: the "Minimal threshold to show a fuzzy match" preference was completely ignored. This is fixed in 2228c117835118a5ea9bf690e8cec9df3a4eef36
-
fix: check the 3 TM scores against fuzzyMatchThreshold
-
The 0/0/100 makes sense because there are no "real words" in common to be matched
-
Matches containing non-alphabetical text are ignored in TM leverage
-
Change merged in 951bbf7
-
The fix can be tested on my fork; https://github.com/briacp/omegat/tree/topic/briac/fix-score-tm-match-1003
-
doc: fix format for topic branch name
-
test: fix to make RealProjectTest test pass on Windows
-
I think it's safe to remove the whole Files.copy(...) on line 453 since we just created a backup moment before during the call to projectOpenImpl (line 616)
-
Error displayed when opening a project on Windows 10
-
Error displayed when opening a project on Windows 10
-
In the branch topic/briacp/note-panel-switch implemented Goto Editor / Goto Notes menu items to navigate between theses panes. Unfortunately, this can't make the panel appear if they're not already visible. I haven't found a way to force changing the dock appearance; I don't think there's already such behavior in OmegaT, maybe it's not possible?
-
feature: shortcuts to navigate between Notes and Editor panel
-
I should have been paying attention to this feature request. This change was already requested in [bugs:#973].
-
Fix bug preventing saving a new script file.
-
Merge branch 'master' of ssh://briac_pilpre@git.code.sf.net/p/omegat/code
-
I didn't know about this feature: it works when you explicitely use the "Replace with Match or Selection" on a match from tm/mt on the active segment (so the red background isn't kept after leaving the segment). If there's a 100% match in a tm/mt entry, it will be used before the segment is activated, thus you will never see the red background. If you have something set in the preference Editor ‣ Prefix, the prefix should always be inserted whatever the match % is so you can check the quality of...
-
Too many glossary hits on right click lead to them displayed off screen
-
Enforced matches are ignored on the CLI with Okapi XLIFF filter
-
I can't reproduce the bug in 5.3.0 and in the current version. When launching from both Powershell and WSL/Ubuntu, the target files have the expected "Enforced translation 1 - DEFAULT" translation and the three TMs are correctly generated.
-
There should be no difference between these two versions. Are you sure you downloaded the same "version" in both case. As the nighty builds are regularly updated maybe the first one didn't include the fix in it?
-
Home
-
Updated test for bug#1015
-
This is fixed in [a0c139f27809e7eb7b99e89f2493acbe45c7a29f]. Only TMX matches with the same language and country as the source language are skipped.
-
Skip entries from the same source language/country (bug#1015)
-
This is fixed in [54931efd88626a74d261d77cf6d718463b5c8c53]. The same behavior as the duplicate segment is used when displaying multiple glossary matches: every 10 matches, a new submenu is added.
-
This is fixed in [efd88626a74d261d77cf6d718463b5c8c53]. The same behavior as the duplicate segment is used when displaying multiple glossary matches: every 10 matches, a new submenu is added.
-
Use MenuItemPager when displaying multiple glossary matches (bug#1009).
-
Tag soup in XML/HTML files
-
Tag soup in XML/HTML files
-
reduced image size
-
Fix bug with double leading slashes in repo file path.
-
Don't take an empty path into account to determine if a file is excluded
-
Merge branch 'topic/briacp/commit-single-target' of
-
Team project improvements
-
Bug#925 Commit files doesn't work if remote dir isn't mapped to "/"
-
Added new menu File -> Commit Current Target File
-
Fix commit target files to multiple repositories
-
Experimental: a local file has always only one mapping (the 'deepest'
-
Always update translation when "Use as default translation" is set.
-
The username can already be specified in Preferences... -> Team -> Name/ID, with the Windows account name filled by default.
-
Actually, the match in your example would be <0/0/95%>. Unfortunately, there is a rule (apparently undocumented) that prevents the third percentage to be calculated if the first two are below the threshold. Since the the last percentage (no tokenization) is less expensive to calculate than the first two, my hunch is that it wouldn't probably hurt performances too much if this rule was removed.
-
application_startup event could fail to execute scripts
-
Fixed in [092f4f1].
-
Choice of GUI language during re-installation is ignored
1 >
