Recent changes to bugs

KFMTWolu

Anonymous — Sun, 17 Mar 2013 04:44:03 -0000

o5InQz <a href="http://awhnhecrkyre.com/">awhnhecrkyre</a>, [url=http://fludxatloedc.com/]fludxatloedc[/url], [link=http://qembqpwdolfn.com/]qembqpwdolfn[/link], http://wibihgvigszr.com/

Find/Replace

Anonymous — Tue, 19 Feb 2013 09:20:14 -0000

When I try to replace some of English word with a Bulgarian one, the program does not recogniize bulgarian text that I insert in place of the English woird and at output shows me only strings of question marks "??????" instead of translated word.

Find/Replace

MEBV — Wed, 13 Feb 2013 15:26:50 -0000

when doing find/replace with an applied filter, every few instances (not regularly but frequently), olifant shows behaviour similar to that described under Bug ID: 2651759. Olifant appears frozen, only right clicking on the taskbar entry of an olifant error message > "Move" > blind left click and drag gets the error message out from under the find/replace window.

the error message is the following:

Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: startIndex
at System.Globalization.CompareInfo.IndexOf(String source, String value, Int32 startIndex, Int32 count, CompareOptions options)
at System.Globalization.CompareInfo.IndexOf(String source, String value, Int32 startIndex)
at Olifant.MatchFinder.Find(String p_sText, Int32 p_nStartIndex, Int32& p_nLengthFound)
at Olifant.MatchFinder.Find(DataRow p_Row, Int32 p_nStartField, Int32 p_nStartPos, Int32 p_nStopField, Int32 p_nStopPos, Int32& p_nField, Int32& p_nLengthFound)
at Olifant.MainForm.FindNext(Boolean p_bShowFRCount, Boolean p_bReplaceMode)
Olifant v3.0.8.0; CC=English (United States); IL=German; OS=Microsoft Windows NT 5.1.2600 Service Pack 3

i am editing a TMX with exactly 100 000 entries (locked as max).

Uploading tmx : ampersand issue

Anonymous — Tue, 27 Nov 2012 08:04:35 -0000

I am trying to convert few TMX file into xl/ csv/ any spreadsheet. When I upload a TMX file in Okapi Olifant TM editor all the ampersand characters are getting changed. Copying and pasting has the same result.

DOCX Sub-document Order

Anonymous — Wed, 14 Nov 2012 17:11:43 -0000

I have experienced an issue in net.sf.okapi.filters.openxml.OpenXMLFilter.nextInZipFile().

I have noticed that the entries that are iterated over are derived from the docx zip file and these entries have a order in the zip file.

For one example document the entries are processed in the following order:

[Content_Types].xml
_rels/.rels
word/_rels/document.xml.rels
word/document.xml
word/theme/theme1.xml
word/settings.xml
word/fontTable.xml
word/webSettings.xml
docProps/app.xml
docProps/core.xml
word/styles.xml

I do have other documents that Word can open correctly that are processed in the following order:

docProps/app.xml
docProps/core.xml
word/document.xml
word/fontTable.xml
word/settings.xml
word/styles.xml
word/webSettings.xml
word/_rels/document.xml.rels
[Content_Types].xml
_rels/.rels

In the first case, OKAPI handles the document properly. In the second it does not, because it is expected by the net.sf.okapi.filters.openxml.OpenXMLFilter.nextInZipFile() method that the [Content_Types].xml precede the word/styles.xml to work properly.

How were these documents created?

The first is generated using Word.

The second is the product of running the first document through Google Translate.

The net.sf.okapi.filters.openxml.OpenXMLFilter.nextInZipFile() needs to be rewritten to account for a different ordering, hunting down the [Content_Types].xml first...

Invalid link

Anonymous — Sun, 20 May 2012 20:46:06 -0000

The link to the TBX specification on page
http://okapi.sourceforge.net/formats.html
is now invalid. A possible replacement could be:
http://www.ttt.org/oscarStandards/tbx/

ampersand

Anonymous — Sun, 11 Mar 2012 22:54:55 -0000

I noticed today that TUs (of a Wordfast memory) with ampersands aren't imported

my workaround was to open the Wordfast memory with Notepad, then manually convert all occurrences of "&" with "and" in the source, as luckily ampersands in Italian are useless ...

I wonder if there is a more "permanent" workaround

Olifant/TMX: bad handling of reserved chars

Eric Voisard — Thu, 15 Dec 2011 16:41:18 -0000

First, thanks for the nice work. Olfiant really helps us!
Though I'd have liked to reopen bug #2971151 about "ascii character" but it's impossible.

When I create a new TMX file and add entries containing some '<' and '>' for example, Olifant does accept to save the file, but then it fails to reopen it, and I get an XML parser exception.

As ysavourel explains in bug #2971151, XML specs forbid some special characters, in particular '&', '<' and '>'. These characters are reserved and must be escaped.
But I don't buy ysavourel workaround (importing TMX files instead of opening them) because that's something you can't do when you're creating new TMX files.

These special characters should be escaped BEFORE to save the file.

Then (and here I'm thinking about translators who are not all XML/HTML specialits), I think Olifant should be capable of replacing XML escape entities with human readable characters before displaying them in the edit boxes and in the grid of the user interface. Olifant could then re-parse changed strings and escape again new reserved chars before to save the strings in the TMX file (a back and forth regexp job).

The internal storage format of the data (TMX/XML) should not interfere with the VIEW for the users in the GUI.

For example I don't mind of MS Word internal file format, what interests me is that it is capable of rendering a readable document.
I think XML formatting, including proper special character escaping, is Olifant's job, not the users one, and it should remain in the background. Users should never have to deal with <, > and the like.

Thanks again for your work, Eric

docx alternatecontent

Anonymous — Mon, 28 Feb 2011 11:34:25 -0000

tikal does not process correctly docx documents with tag mc:AlternateContent in document.xml
The result document after merging xlf with original is not valid docx document.

Olifant bug - tmx import - ascii character

Anonymous — Tue, 16 Mar 2010 09:14:42 -0000

[view attached file for description of error]