Activity for Gabix
-
Gabix posted a comment on ticket #45
В загрузках файл с похоже битым расширением (ср. размер 5,3 МиБ для 3.5.1 и 4,4 МиБ для 3.5.2).
-
Add Kazakh tenge sign
-
So, here is one more report. DSL supports a variety of colors for the [c] tag. However, OmegaT shows only the following: aqua blue fuchsia gray green lime maroon navy olive orange purple red silver teal white yellow All other colors turn into black (tested with the binaries of 22 and 25 September from this thread). To reproduce, open the attached project and see the dictionary tab (if you fetch the dictionary to GoldenDict, you’ll see the whole palette). The question is: where is the limitation?...
-
So, here is one more report. DSL supports a variety of colors for the [c] tag. However, OmegaT shows only the following: aqua blue fuchsia gray green lime maroon navy olive orange purple red silver teal white yellow All other colors turn into black (tested with the binaries of 22 and 25 September from this thread). To reproduce, open the attached project and see the dictionary tab (if you fetch the dictionary to GoldenDict, you’ll see the whole palette).
-
I am Dmitri Gabinski. Thanks for adding me :)
-
Unfortunately, trying to download the compiled JAR, I get an incomplete file of just 4.5 MiB.
-
Unfortunately, this build does not load my test dictionary (the previous one does, although ignoring multimedia items). Attaching a modified test case.
-
At least, GoldenDict renders PNG files correctly when they are referenced to in [s] tags. Unfortunately, I do not have ABBYY Lingvo at hand to test.
-
Looks like worth trying. I’d also suggest: reList.add(new RE("\\[s\\](.+?\\.tif)\\[/s\\]", "<img src=\"file://$1\"/>")); reList.add(new RE("\\[s\\](.+?\\.tiff)\\[/s\\]", "<img src=\"file://$1\"/>")); reList.add(new RE("\\[s\\](.+?\\.png)\\[/s\\]", "<img src=\"file://$1\"/>"));
-
The brackets are fixed now, great! Now, I can see a minor issue: some colors are reproduced when specified as the values of the c tag, some are not. In the above test case: a) red, blue, fuchsia, gray, purple, green are fine; b) darkviolet, midnightblue, indigo, darkred turn into black. As far as I understand, the DSL markup uses standard HTML color names. I will test further.
-
Yes, the contents can be ignored, unless you (or someone else) undertakes to implement a viewer for images. The same applies to preview and video tags. But, as I see, you already suggest a solution for images.
-
I upvoted that suggestion.
-
Yes, the contents can be ignored, unless you (or someone else) undertakes to implement a viewer for images. The same applies to preview and video tags.
-
Oops, my suggestion does not work. The [ and ] codes show up literally, not converted to brackets (attaching a screenshot). Perhaps, using [ and ], as per your suggestion, would work better.
-
Maybe, \[ as [ and \] as ]?
-
本当にクールですよ！ I’ve tested the binary with a couple of dictionaries and find it excellent. Dictionary articles appear fine. I will test further, but so far I can’t see anything that would need an immediate correction, except for one thing: in some dictionaries, square brackets are escaped as \[ and \]. Escaping works similarly to bracket duplication. Now, they appear as \[ and \] respectively instead of just [ and ]. Attaching a test case. P. S. Sorry, I did not report it earlier. I guess, I missed it...
-
本当にクールですよ！ I’ve tested the binary with a couple of dictionaries and find it excellent. Dictionary articles appear fine. I will test further, but so far I can’t see anything that would need an immediate correction, except for one thing: in some dictionaries, square brackets are escaped as \[ and \]. Escaping works similarly to bracket duplication. Now, they appear as [ and ] respectively instead of just [ and ]. Attaching a test case. P. S. Sorry, I did not report it earlier. I guess, I missed it...
-
I’d suggest no indent for m0, single indent for m and m1, double indent for m2, triple for the rest, as follows: RE_MAP.add(new RegMap("\\[m0\\](.+?)\\[/m0\\]", "<p>$1</p>")); RE_MAP.add(new RegMap("\\[m\\](.+?)\\[/m\\]", "<p style="text-indent: 30px">$1</p>")); RE_MAP.add(new RegMap("\\[m1\\](.+?)\\[/m1\\]", "<p style="text-indent: 30px">$1</p>")); RE_MAP.add(new RegMap("\\[m2\\](.+?)\\[/m2\\]", "<p style="text-indent: 60px">$1</p>")); RE_MAP.add(new RegMap("\\[m3\\](.+?)\\[/m3\\]", "<p style="text-indent:...
-
Yes, these rules are correct. However, since OmegaT shows dictionary articles as single lines anyway, processing the mX tags seems excessive, so I suggested omitting them in the above piece of code in the following part: + RE_MAP.add(new RegMap("\\[m\\]", "")); + RE_MAP.add(new RegMap("\\[/m\\]", "")); + RE_MAP.add(new RegMap("\\[m1\\]", "")); + RE_MAP.add(new RegMap("\\[/m1\\]", "")); + RE_MAP.add(new RegMap("\\[m2\\]", "")); + RE_MAP.add(new RegMap("\\[/m2\\]", "")); + RE_MAP.add(new RegMap("\\[m3\\]",...
-
Yes, these rules are correct. However, since OmegaT shows dictionary articles as single lines anyway, processing the mX tags seems excessive, so I suggested omitting them in the above piece of code in the following part: + RE_MAP.add(new RegMap("\\[m\\]", "")); + RE_MAP.add(new RegMap("\\[/m\\]", "")); + RE_MAP.add(new RegMap("\\[m1\\]", "")); + RE_MAP.add(new RegMap("\\[/m1\\]", "")); + RE_MAP.add(new RegMap("\\[m2\\]", "")); + RE_MAP.add(new RegMap("\\[/m2\\]", "")); + RE_MAP.add(new RegMap("\\[m3\\]",...
-
Yes, these rules are correct. However, since OmegaT shows dictionary articles as single lines anyway, processing the mX tags seems excessive, so I suggested omitting them in the above piece of code in the following part: + RE_MAP.add(new RegMap("\\[m\\]", "")); + RE_MAP.add(new RegMap("\\[/m\\]", "")); + RE_MAP.add(new RegMap("\\[m1\\]", "")); + RE_MAP.add(new RegMap("\\[/m1\\]", "")); + RE_MAP.add(new RegMap("\\[m2\\]", "")); + RE_MAP.add(new RegMap("\\[/m2\\]", "")); + RE_MAP.add(new RegMap("\\[m3\\]",...
-
I have added more tag replacements as follows (I commented some cases when tags are not just dropped: static { RE_MAP.add(new RegMap("\\[b\\](.+?)\\[/b\\]", "<strong>$1</strong>")); RE_MAP.add(new RegMap("\\[i\\](.+?)\\[/i\\]", "<span style='font-style: italic'>$1</span>")); RE_MAP.add(new RegMap("\\[trn\\]", "")); RE_MAP.add(new RegMap("\\[/trn\\]", "")); RE_MAP.add(new RegMap("\\[t\\]", "")); RE_MAP.add(new RegMap("\\[/t\\]", "")); + RE_MAP.add(new RegMap("\\[br\\]", "<br/>")); + //The following...
-
As far as I understand this code, it is a sort of ‘kill-em-all’ approach. I downloaded the 5.5.0 source code, opened in NetBeans 8.0.2 and tried to modify the code to specifically list DSL tags as follows (it won’t be a good solution, though): protected static final Pattern RE_SKIP = Pattern.compile("\\[[b|/b|i|/i|u|/u|c|/c|sup|/sup|sub|/sub|m|/m|m1|/m1|m2|/m2|m3|/m3|'|/'|br|p|/p|t|/t|\\*|/\\*|ex|/ex|com|/com|trn|/trn|trn1|/trn1|\\!trs|/\\!trs|lang|/lang|s|/s|video|/video|ref|/ref|url|/url]\\]");...
-
DSL dictionaries: brackets processed incorrectly
-
Done: https://sourceforge.net/p/omegat/feature-requests/1393/
-
Extract Text Content script to xport to UTF-8
-
Is it possible to modify the script to force output in UTF-8? It exports (tested the script as included into the OmegaT 4.1.5 package) to the system default encoding which may be bad for many language pairs. For example, the output for a FR→RU project on Windows/Russian locale results in lost French characters with diacritics (question marks placed instead) as this locale uses cp1251 where the mentioned chars are missing.
-
PDF files section in FilesToTranslate
-
Character count for separate lines in segment
-
Several issues in user manual
-
Incorrect shortcut in Chapter 5 of user manual
-
Thanks for the pointer. Indeed, changing the tokenizer to Hunspell fixed the problem....
-
I am afraid, I see nothing to add to the original report. Anyway, find attached a...
-
Please, re-open this ticket. The problem is back in 3.6.0, at least in the snapshot,...
-
Thanks! Seems fine to me (as built from source downloaded today). Belarusian words...
-
Под Windows не бывает 64-битных сборок, по крайней мере, с офсайта. «С разными документами»...
-
2.31: аварийное завершение при выборе Text Formatting
1