Activity for Aaron Madlon-Kay
-
Aaron Madlon-Kay posted a comment on ticket #19958
This ticket was acted on years ago now. Perhaps it can be closed, now that it's being targeted by spammers?
-
Re-opening because I have changed the scope of the ticket. It is a plausible request, though not one I would recommend anyone use.
-
Pre-translate with machine translation
-
Re-opening because I have changed the scope of the ticket. It is a reasonable request, though not one I would recommend anyone use.
-
OmegaT does not currently have a concept of "batch tasks". Further, it is a non-goal of OmegaT to facilitate machine pretranslation. I will not develop such a feature, but would potentially accept such a contribution. In the meantime, this could be achieved with a script. Someone may have created one already; I would ask in the user group.
-
Pre-translate with machine translation
-
OmegaT does not have a concept of "batch tasks". Further, it is a non-goal of OmegaT to facilitate machine pretranslation. I will not develop such a feature, but would potentially accept such a contribution. In the meantime, this could be achieved with a script. Someone may have created one already; I would ask in the user group.
-
You can already pretranslate 100% matches by putting your TM in tm/auto. There is no need for a "batch task" step. If that doesn't cover your use case, please be more specific about what you are looking for.
-
I think the desirability of a two-column layout depends a lot on the material being worked on. OmegaT's "inline" style makes a lot of sense for documents, but I would also probably prefer two-column for things like software strings. The issue isn't whether it would be good to have or not (I definitely would like to have it). The issue is that it's an extremely large change to the program, and no one with the requisite skill, time, and interest has shown up to do it.
-
Calling glossarySupplier.get() gets java.lang.NullPointerException
-
Thanks for investigating!
-
One thing I can say is that the glossary supplier is set when the MT pane is initialized, so if you're adding the connector afterwards via a script then it won't have a supplier. You can look at the default supplier implementation. Unfortunately getGlossaryMap is not public and you can't get a reference to currentlyProcessedEntry from outside of MachineTranslateTextArea, so it looks like it's not really feasible to get an identical supplier right now.
-
Calling glossarySupplier.get() gets java.lang.NullPointerException
-
Your usage code is not complete, so I can't tell what is wrong. Please supply more context so I can tell where in the MT connector lifecycle you are calling glossarySupplier.get(). I would suggest that in the future you address usage questions to the omegat-development mailing list instead of assuming a bug.
-
Enforced ID-bound alternative translations not recognized
-
Thanks for your help diagnosing this and for your proposed fix. I think your proposed fix is almost correct; the only problem I see is that I think it would allow for any subsequently encountered default enforced translation to override an existing default enforced translation. That would go against the intent of [bf52b2], which was to only allow use of the first-encountered enforced translation. I've pushed a fix to master ([2f531b]). It appears to handle your test case correctly. Please let me...
-
Spelling dictionaries download site closed
-
Spelling dictionaries download site closed
-
Fixed in 4.3.3 and 5.7.1.
-
OmegaT standard version 4.3.3 and latest version 5.7.0 released
-
Fixed in [6c80fe] on standard branch.
-
Spelling dictionaries download site closed
-
Spelling dictionaries site closed
-
Thanks for taking initiative on this. I will (hopefully this weekend) sit down and try to understand The problem that [bf52b2] was intended to fix and how exactly [bf52b2] fixed it What the correct behavior should be in light of all this Whether your patch gets us to the correct behavior My suspicion is that the undesired behavior is an oversight, so hopefully the path forward should be clear. But it's also possible that, for instance, we might back out [bf52b2] entirely. Taking a quick look at your...
-
The next thing to do is figure out which change between 5.2 and 5.3 caused the behavior. If you are comfortable building OmegaT then it's "just" a matter of doing the following. Check out source at a particular commit. You would probably start with the v5.2.0 tag. Build and run or just run (./gradlew run) OmegaT See if the behavior is the undesired pattern If no, repeat from top with the next commit Looking at the change history I see [bf52b2] looks quite suspicious.
-
Thanks for the report. The best way you can help get this fixed faster is if you can identify in which version of OmegaT the behavior first changed.
-
Inquiries about OmegaT
-
Clarify requirements for DeepL API key
-
Clarify requirements for DeepL API key
-
Ticket moved from /p/omegat-plugins/feature-requests/9/
-
Ticket moved from /p/omegat/bugs/1087/
-
We have anecdotal confirmation from a user that they have a DeepL API key that works as of March 2022. So we will not be removing the connector. It seems that either the "Advanced" or "Ultimate" plans are required. Indeed, their plan comparison notes that "CAT tool integration" is included with "Advanced" and above. So it would be useful to note that in the UI.
-
We have anecdotal confirmation from a user that they have a DeepL API key that works as of March 2022. So we will not be removing the connector. It seems the key is simply that either the "Advanced" or "Ultimate" plans are required. Indeed, their plan comparison notes that "CAT tool integration" is included with "Advanced" and above. So it would be useful to note that in the UI.
-
OmegaT default colors can be lost when a plugin fails to initialize
-
Fixed in [4adb9b] on master.
-
Ticket moved from /p/omegat/feature-requests/1607/
-
@miurahr9 Is this not a bug given your work on https://github.com/omegat-org/omegat/pull/201 ? If a plugin throwing an exception on init causes us to lose some sort of configuration then that does seem like a bug.
-
Unless things have changed I think you can still get v1 keys, but they don't work for API access. So just saying "v1" isn't enough; only people with old-enough v1 keys can use it. Someone™ should figure out the current state of affairs: Can you still get v1 keys? Are "old" v1 keys still able to access the API? What exactly was the cutoff date? If old v1 keys still work and we can determine the cutoff date, then we can give meaningful guidance to users. If old v1 keys can no longer use the API then...
-
Unless things have changed I think you can still get v1 keys, but they don't work for API access. So just saying "v1" isn't enough; only people with old-enough v1 keys can use it. Someone™ should figure out the current state of affairs: - Can you still get v1 keys? - Are "old" v1 keys still able to access the API? - What exactly was the cutoff date? If old v1 keys still work and we can determine the cutoff date, then we can give meaningful guidance to users. If old v1 keys can no longer use the API...
-
Unless you have new information that something has changed such that even the older keys are not usable?
-
This has been the case for years. API keys that were created before a certain point can still use their API v1, which is why we have kept the MT connector.
-
Looking further into the issue. The DeepLTranslate.java in 5.7.0 uses the V1 API: https://api.deepl.com/v1/translate Formally, DeepL has deprecated the V1 API in 2018. According to https://www.deepl.com/docs-api/accessing-the-api/api-versions/, DeepL provides the API V1 for use with CAT tool integrations. However, at least my API key does not allow access to https://api.deepl.com/v1/usage, returning a 403 with message: { "message": "This account is not allowed to access the API." } But https://api.deepl.com/v2/usage...
-
As I understand it, DeepL API v1 is deprecated, but v2 is not available. This has been the case for years(?). API keys issued prior to some cutoff still work with API v1, whereas newer keys only work with v2. If you are in the latter group, you are simply out of luck until DeepL allows external use of API v2.
-
While making Glossary entry, it shows boxes for Santali (Ol Chiki)
-
Duplicate of [#888]
-
This is not a bug; it's a feature request It duplicates [feature-requests:#1599]
-
No support for TBX version 3?
-
This is not a bug; it's a feature request It duplicates [feature-requests:#1599]
-
No support for TBX version 3?
-
Duplicate of [#1084]
-
It looks like jieba-analysis is available on Maven Central, so unless you really need the latest snapshot then you could do this instead of placing the JAR locally: implementation 'com.huaban:jieba-analysis:1.0.2' Don't know if this is also necessary. I've added dependencies in both places. That's only necessary if you want the "source" distribution to work correctly. But I'm not aware how to build an Installer for Windows. Could you help? The easiest way is to place one of these Windows JRE .zip...
-
It looks like jieba-analysis is available on Maven Central, so unless you really need the latest snapshot then you could do this instead of placing the JAR locally: implementation 'com.huaban:jieba-analysis:1.0.2' Don't know if this is also necessary. I've added dependencies in both places. That's only necessary if you want the "source" distribution to work correctly. But I'm not aware how to build an Installer for Windows. Could you help? The easiest way is to place one of these Windows JRE .zip...
-
Use an Array to store punctuations in original source text, and replace back after being smart tokenized (using tokenizeWordsToStrings), for Chinese srcLang. Use other more generally used tokenizers to replace lucene. For (1) I am not sure if it's feasible to post hoc "fix" the output. If it can be done, then that would be acceptable. For (2), sure, if the library is available on Maven Central under an appropriate license, and someone wants to take on that work. To be clear, I am not planning to...
-
Use an Array to store punctuations in original source text, and replace back after being smart tokenized (using tokenizeWordsToStrings), for Chinese srcLang. Use other more generally used tokenizers to replace lucene. For (1) I am not sure if it's feasible to post hoc "fix" the output. If so, that would be acceptable. For (2), sure, if the library is available on Maven Central under an appropriate license, and someone wants to take on that work. To be clear, I am not planning to take on either of...
-
Use an Array to store punctuations in original source text, and replace back after being smart tokenized (using tokenizeWordsToStrings), for Chinese srcLang. Use other more generally used tokenizers to replace lucene. For (1) I am not sure if it's feasible to post hoc "fix" the output. If so, that would be acceptable. For (2), sure, if the library is available on Maven Central under an appropriate license, and someone wants to take on that work. To be clear, I am not planning to take on either of...
-
Hi Aaron, Thanks for the info. Based on your script, I've tried following script and found that when using “tokenizeVerbatimToStrings” method and "tokenizeWordsToStrings", we get unigram and smart tokenized results, respectively. Though "tokenizeWordsToStrings" replaced all punctuations with "，". import org.omegat.util.Language import org.omegat.tokenizer.LuceneSmartChineseTokenizer import org.omegat.tokenizer.ITokenizer.StemmingMode import java.util.Locale def str = "中文测试代码是这样写的：如果测试一下，就可以知道。" def...
-
could you think of a better solution than adding options for sorting? Yes, and I described it in my previous comment.
-
I took another look and we are explicitly disallowing using the SmartChineseAnalyzer for verbatim tokenization. Verbatim tokenization is where you are simply splitting up the input string with no other changes, such that (in pseudocode) tokenize(str).join() == str. "Other changes" are things like stemming or lemmatizing, whitespace collapsing, etc. The reason we can't use SmartChineseAnalyzer for verbatim tokenization is because it replaces all punctuation with ,. You can see this if you run the...
-
I took another look and we are explicitly disallowing using the SmartChineseAnalyzer for verbatim tokenization. Verbatim tokenization is where you are simply splitting up the input string with no other changes, such that (in pseudocode) tokenize(str).join() == str. "Other changes" are things like stemming or lemmatizing, whitespace collapsing, etc. The reason we can't use SmartChineseAnalyzer for verbatim tokenization is because it replaces all punctuation with ,. You can see this if you run the...
-
I don't think this is quite a good idea as stated. First, I don't like the idea of adding yet another fiddly option to the GUI. This is not something people should have to care about. Second, I think we have an X Y problem here. It sounds like what you really want is to ensure some specific ordering for enforced matches of equal score. (That is not the same as "I want to be able to choose whether matches are sorted in ascending or descending order by file path".) In the case of matches that differ...
-
It's not clear to me whether the tokenizer is actually not behaving as expected, or if your example sentence was simply an unfortunate one that didn't work well with the default dictionary. This page indicates that "我是中国人" should tokenize to [我, 是, 中国, 人]. Does that example work as expected for you?
-
It looks like it's quite difficult to replace the built-in dictionary: https://github.com/apache/lucene/commit/5265dc1bb206a84a82db4129ac12962ef5260660#diff-4d4da007bcf3baddfd26b3c1318e151943ccda2a83f23d7c700c296d1a1b57ea
-
The OmegaT Moses connector uses the project's source-language tokenizer to tokenize before sending to Moses. What tokenizer are you using? See the Project menu > Properties > Source Language Tokenizer. The LuceneSmartChineseTokenizer is supposed to segment by word, not by unigram, according to this. Is that not what you're seeing?
-
Integrating NLP Chinese tokenization for Moses machine translation
-
The OmegaT Moses connector uses the project's source-language tokenizer to tokenize before sending to Moses. What tokenizer are you using? See the Project menu > Properties > Source Language Tokenizer. The LuceneSmartChineseTokenizer is supposed to segment by word, not by monogram, according to this. Is that not what you're seeing?
-
Support sound links in Dictionary pane
-
Implemented in OmegaT 5.7.0.
-
Improve support for markup in DSL dictionaries
-
Implemented in OmegaT 5.7.0.
-
Display images in Dictionary pane
-
Implemented in OmegaT 5.7.0.
-
Ignore Microsoft Office temporary files
-
Implemented in OmegaT 5.7.0.
-
Dictionary pane update is extremely slow for large articles
-
Fixed in OmegaT 5.7.0.
-
Menus don't get keyboard focus after opening
-
Fixed in OmegaT 5.7.0.
-
OmegaT latest version 5.7.0 released
-
Support sound links in Dictionary pane
-
This was implemented in [91d272] on master.
-
Right click menu on button in Scripting window doesn't work
-
Thanks for the report. This is actually a symptom of the same cause as [#1073]. It's fixed in master, so you can use a nightly build while I prepare the 5.7 release.
-
Report error if translated document is not successfully created
-
Because there were reports of problems with the Dictionary pane that were (hopefully) addressed by improvements in 5.7, I would prefer to release 5.7 soon.
-
Example TBX from IATE <?xml version='1.0' encoding='UTF-8'?> <?xml-model href="./TBX-IATE_DCA.sch" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> <?xml-model href="./TBXcoreStructV03_TBX-IATE_integrated.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> <tbx type="TBX-IATE" style="dca" xml:lang="en" xmlns="urn:iso:std:iso:30042:ed-2"> <tbxHeader> <fileDesc> <titleStmt> <title>IATE dataset</title> </titleStmt> <sourceDesc> <p>This is a TBX...
-
Example TBX from IATE <?xml version='1.0' encoding='UTF-8'?> <?xml-model href="./TBX-IATE_DCA.sch" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?> <?xml-model href="./TBXcoreStructV03_TBX-IATE_integrated.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?> <tbx type="TBX-IATE" style="dca" xml:lang="en" xmlns="urn:iso:std:iso:30042:ed-2"> <tbxHeader> <fileDesc> <titleStmt> <title>IATE dataset </title> </titleStmt> <sourceDesc> <p>This is a TBX...
-
Support TBX v3
-
Ticket moved from /p/omegat/bugs/1079/
-
I don't have an IATE account so I can't confirm, but I guess the "new" TBX files are v3 (root element <tbx>), which OmegaT doesn't support. OmegaT only supports TBX v2 (root element <martif>).
-
Menus don't get keyboard focus after opening
-
This was an unintended side-effect of [feature-requests:#1567]. It's now fixed in master in [c05f39].
-
Thank you for looking into this, Hiroshi. I have to say that your solution appears correct, but it is a frustrating one. We are implementing the LookAndFeel interface and delegating all its methods to the system LAF; if the system LAF is a BasicLookAndFeel then that should be sufficient. However it seems that Swing gives BasicLookAndFeel LAFs special treatment for instance here and here so it is not enough to behave like a BasicLookAndFeel; we must also be a BasicLookAndFeel.
-
Thanks for looking at this. I don't see a good way forward beyond bisecting to find the commit that caused the issue, and then analyzing that.
-
Related [bugs:#1075] Pull-Request: github
-
Related [bugs#1075] Pull-Request: github
-
@miurahr9 Any idea about this?
-
I think it's probably rare enough that it will be fine. If not, we can always adjust it later.
-
Implemented on master in [c64251].
-
Ignore Microsoft Office temporary files
-
Apparently these are "owner files"; see https://superuser.com/a/405258/93651 It looks reasonable to just ignore **/~$* rather than try to enumerate all Office file extensions.
1 >
