> This does work:
>
>   <okp:options extractIfOnlyCodes="no"/>
>   <okp:options omitXMLDeclaration="yes"/>

With this order omitting the XML Declaration fails.

Hi Frank,

The order of the options should not affect their results.
I've filled an issue for this:
http://code.google.com/p/okapi/issues/detail?id=227

Thanks for the report,
-yves

-----Original Message-----
From: okapitools@yahoogroups.com [mailto:okapitools@yahoogroups.com] On Behalf
Of frankralf
Sent: Tuesday, May 08, 2012 7:14 AM
To: okapitools@yahoogroups.com
Subject: [okapitools] Re: RTF layer settings?

Hi Yves,

> My test is probably different from your files somewhere. Maybe the ITS rules?

I did another run with your above test file and to my surprise this time _both_
PIs were marked red. After quite some investigating (and tearing my hair) I
found that strangely the order of the ITS rules seems to matter:

This does work:

   <okp:options extractIfOnlyCodes="no"/>
   <okp:options omitXMLDeclaration="yes"/>

While this doesn't:

   <okp:options omitXMLDeclaration="yes"/>
   <okp:options extractIfOnlyCodes="no"/>

Is this the expected behavior or is it a bug?

Kind regards,
Frank







------------------------------------

Yahoo! Groups Links

Hello

I can't quite see the logic of the IFF function although it has been explained
to me (IFF only I could understand!!)


Here is my formula

IIF([Text_SV_SE] ='Bitar', LEN([Text_SV_SE] )>2, LEN([Text_SV_SE] )>5000)


As the word 'bitar' is longer than 2 characters, I expect the filter to let thru
ALL sentences where the word 'bitar' is found and very long TU's (>5000)

But it doesn't.

I expected that

IIF([Text_SV_SE] ='Bitar', LEN([Text_SV_SE] )>20, LEN([Text_SV_SE] )>5000)

would display short sentences where 'bitar' is found and extremely long TU's
(>5000) as well

But it doesn't

They both give 0 filter results but yet the filter is running

I just don't get the 'logic'

Can anyone explain please

Thanks

Hi SafeTex,

Your initial condition is whether or not the text of Text_SV_SE equals 'Bitar'.
Any entry corresponding to that condition will always be the same text length of
5 characters.

You don't need to use IIF for this query.

To get any entry where the text of Text_SV_SE contains 'Bitar' try: (Text_SV_SE
LIKE '%Bitar%')

To get any entry where the text of Text_SV_SE contains 'Bitar' and the total
length of Text_SV_SE is longer than 20, try: (Text_SV_SE LIKE '%Bitar%') AND
(LEN(Text_SV_SE)>20)

Etc.

Hope this helps,
-yves


-----Original Message-----
From: okapitools@yahoogroups.com [mailto:okapitools@yahoogroups.com] On Behalf
Of SafeTex
Sent: Friday, May 11, 2012 1:31 AM
To: okapitools@yahoogroups.com
Subject: [okapitools] IFF: Little explanation please

Hello

I can't quite see the logic of the IFF function although it has been explained
to me (IFF only I could understand!!)


Here is my formula

IIF([Text_SV_SE] ='Bitar', LEN([Text_SV_SE] )>2, LEN([Text_SV_SE] )>5000)


As the word 'bitar' is longer than 2 characters, I expect the filter to let thru
ALL sentences where the word 'bitar' is found and very long TU's (>5000)

But it doesn't.

I expected that

IIF([Text_SV_SE] ='Bitar', LEN([Text_SV_SE] )>20, LEN([Text_SV_SE] )>5000)

would display short sentences where 'bitar' is found and extremely long TU's
(>5000) as well

But it doesn't

They both give 0 filter results but yet the filter is running

I just don't get the 'logic'

Can anyone explain please

Thanks



------------------------------------

Yahoo! Groups Links

Hello

That makes perfect sense when I read it but still leaves me wondering then how
and when to use IFF

Can you give me an example please (another one than a few weeks ago) where it
would make sense to use it

Thanks

--- In okapitools@yahoogroups.com, "Yves Savourel" <yves@...> wrote:
>
> Hi SafeTex,
>
> Your initial condition is whether or not the text of Text_SV_SE equals
'Bitar'. Any entry corresponding to that condition will always be the same text
length of 5 characters.
>
> You don't need to use IIF for this query.
>
> To get any entry where the text of Text_SV_SE contains 'Bitar' try:
(Text_SV_SE LIKE '%Bitar%')
>
> To get any entry where the text of Text_SV_SE contains 'Bitar' and the total
length of Text_SV_SE is longer than 20, try: (Text_SV_SE LIKE '%Bitar%') AND
(LEN(Text_SV_SE)>20)
>
> Etc.
>
> Hope this helps,
> -yves
>
>
> -----Original Message-----
> From: okapitools@yahoogroups.com [mailto:okapitools@yahoogroups.com] On Behalf
Of SafeTex
> Sent: Friday, May 11, 2012 1:31 AM
> To: okapitools@yahoogroups.com
> Subject: [okapitools] IFF: Little explanation please
>
> Hello
>
> I can't quite see the logic of the IFF function although it has been explained
to me (IFF only I could understand!!)
>
>
> Here is my formula
>
> IIF([Text_SV_SE] ='Bitar', LEN([Text_SV_SE] )>2, LEN([Text_SV_SE] )>5000)
>
>
> As the word 'bitar' is longer than 2 characters, I expect the filter to let
thru ALL sentences where the word 'bitar' is found and very long TU's (>5000)
>
> But it doesn't.
>
> I expected that
>
> IIF([Text_SV_SE] ='Bitar', LEN([Text_SV_SE] )>20, LEN([Text_SV_SE] )>5000)
>
> would display short sentences where 'bitar' is found and extremely long TU's
(>5000) as well
>
> But it doesn't
>
> They both give 0 filter results but yet the filter is running
>
> I just don't get the 'logic'
>
> Can anyone explain please
>
> Thanks
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>

Hello

I wanted to have a little look at Rainbow today which I downloaded about a month
ago but it won't run

If I try to run it from Olifant, I get the type of message that makes me want to
make for the hills (see below)

If I click directly on the Rainbow.exe, nothing happens either

Any pointers please?

Thanks


See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an
object.
    at Okapi.Library.Base.Routines.GetOkapiFolder()
    at Olifant.MainForm.m_miStartRainbow_Click(Object sender, EventArgs e)
    at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
    at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
    at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
    at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
    at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
    at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
    at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button,
Int32 clicks)
    at System.Windows.Forms.Control.WndProc(Message& m)
    at System.Windows.Forms.ToolStrip.WndProc(Message& m)
    at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
    at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
    at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr
wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
     Assembly Version: 2.0.0.0
     Win32 Version: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
     CodeBase:
file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
----------------------------------------
Olifant
     Assembly Version: 3.0.8.0
     Win32 Version: 3.0.8.0
     CodeBase: file:///C:/Program%20Files%20(x86)/Okapi/Olifant/Olifant.exe
----------------------------------------
System.Windows.Forms
     Assembly Version: 2.0.0.0
     Win32 Version: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
     CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e\
089/System.Windows.Forms.dll
----------------------------------------
System
     Assembly Version: 2.0.0.0
     Win32 Version: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
     CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
     Assembly Version: 2.0.0.0
     Win32 Version: 2.0.50727.5458 (Win7SP1GDR.050727-5400)
     CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/Sy\
stem.Drawing.dll
----------------------------------------
Okapi.Library.Base
     Assembly Version: 1.0.17.0
     Win32 Version: 1.0.17.0
     CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/Okapi.Library.Base/1.0.17.0__5e78ed90c17624\
66/Okapi.Library.Base.dll
----------------------------------------
Okapi.Library.Segmentation
     Assembly Version: 1.0.17.0
     Win32 Version: 1.0.17.0
     CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/Okapi.Library.Segmentation/1.0.17.0__77a2a0\
87340b0ec9/Okapi.Library.Segmentation.dll
----------------------------------------
Okapi.TM.Engine
     Assembly Version: 1.0.5.0
     Win32 Version: 1.0.5.0
     CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/Okapi.TM.Engine/1.0.5.0__a969eeed1cf92e4f/O\
kapi.TM.Engine.dll
----------------------------------------
System.Xml
     Assembly Version: 2.0.0.0
     Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
     CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System\
.Xml.dll
----------------------------------------
Okapi.Library.UI
     Assembly Version: 1.0.18.0
     Win32 Version: 1.0.18.0
     CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/Okapi.Library.UI/1.0.18.0__c3b51f7b3ca8b843\
/Okapi.Library.UI.dll
----------------------------------------
System.Data
     Assembly Version: 2.0.0.0
     Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
     CodeBase:
file:///C:/Windows/assembly/GAC_64/System.Data/2.0.0.0__b77a5c561934e089/System.\
Data.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
     <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

I think you are trying to use the old .NET based Rainbow. Try using the
new Java based Rainbow, which can be gotten at http://okapi.opentag.com

Regards,

Piotr


On Fri, 11 May 2012 15:33:54 -0000, "SafeTex" <daveneve@...> wrote:
> Hello
>
> I wanted to have a little look at Rainbow today which I downloaded about
a
> month ago but it won't run
>
> If I try to run it from Olifant, I get the type of message that makes me
> want to make for the hills (see below)
>
> If I click directly on the Rainbow.exe, nothing happens either
>
> Any pointers please?
>
> Thanks
>
>
> See the end of this message for details on invoking
> just-in-time (JIT) debugging instead of this dialog box.
>
> ************** Exception Text **************
> System.NullReferenceException: Object reference not set to an instance
of
> an object.
>    at Okapi.Library.Base.Routines.GetOkapiFolder()
>    at Olifant.MainForm.m_miStartRainbow_Click(Object sender, EventArgs
e)
>    at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key,
EventArgs
>    e)
>    at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
>    at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
>    at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
>    at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
>    at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs
mea)
>    at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons
>    button, Int32 clicks)
>    at System.Windows.Forms.Control.WndProc(Message& m)
>    at System.Windows.Forms.ToolStrip.WndProc(Message& m)
>    at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
>    at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message&
m)
>    at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg,
>    IntPtr wparam, IntPtr lparam)
>
>
> ************** Loaded Assemblies **************
> mscorlib
>     Assembly Version: 2.0.0.0
>     Win32 Version: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
>     CodeBase:
>     file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
> ----------------------------------------
> Olifant
>     Assembly Version: 3.0.8.0
>     Win32 Version: 3.0.8.0
>     CodeBase:
file:///C:/Program%20Files%20(x86)/Okapi/Olifant/Olifant.exe
> ----------------------------------------
> System.Windows.Forms
>     Assembly Version: 2.0.0.0
>     Win32 Version: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
>     CodeBase:
>
file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e\
089/System.Windows.Forms.dll
> ----------------------------------------
> System
>     Assembly Version: 2.0.0.0
>     Win32 Version: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
>     CodeBase:
>
file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
> ----------------------------------------
> System.Drawing
>     Assembly Version: 2.0.0.0
>     Win32 Version: 2.0.50727.5458 (Win7SP1GDR.050727-5400)
>     CodeBase:
>
file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/Sy\
stem.Drawing.dll
> ----------------------------------------
> Okapi.Library.Base
>     Assembly Version: 1.0.17.0
>     Win32 Version: 1.0.17.0
>     CodeBase:
>
file:///C:/Windows/assembly/GAC_MSIL/Okapi.Library.Base/1.0.17.0__5e78ed90c17624\
66/Okapi.Library.Base.dll
> ----------------------------------------
> Okapi.Library.Segmentation
>     Assembly Version: 1.0.17.0
>     Win32 Version: 1.0.17.0
>     CodeBase:
>
file:///C:/Windows/assembly/GAC_MSIL/Okapi.Library.Segmentation/1.0.17.0__77a2a0\
87340b0ec9/Okapi.Library.Segmentation.dll
> ----------------------------------------
> Okapi.TM.Engine
>     Assembly Version: 1.0.5.0
>     Win32 Version: 1.0.5.0
>     CodeBase:
>
file:///C:/Windows/assembly/GAC_MSIL/Okapi.TM.Engine/1.0.5.0__a969eeed1cf92e4f/O\
kapi.TM.Engine.dll
> ----------------------------------------
> System.Xml
>     Assembly Version: 2.0.0.0
>     Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
>     CodeBase:
>
file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System\
.Xml.dll
> ----------------------------------------
> Okapi.Library.UI
>     Assembly Version: 1.0.18.0
>     Win32 Version: 1.0.18.0
>     CodeBase:
>
file:///C:/Windows/assembly/GAC_MSIL/Okapi.Library.UI/1.0.18.0__c3b51f7b3ca8b843\
/Okapi.Library.UI.dll
> ----------------------------------------
> System.Data
>     Assembly Version: 2.0.0.0
>     Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
>     CodeBase:
>
file:///C:/Windows/assembly/GAC_64/System.Data/2.0.0.0__b77a5c561934e089/System.\
Data.dll
> ----------------------------------------
>
> ************** JIT Debugging **************
> To enable just-in-time (JIT) debugging, the .config file for this
> application or computer (machine.config) must have the
> jitDebugging value set in the system.windows.forms section.
> The application must also be compiled with debugging
> enabled.
>
> For example:
>
> <configuration>
>     <system.windows.forms jitDebugging="true" />
> </configuration>
>
> When JIT debugging is enabled, any unhandled exception
> will be sent to the JIT debugger registered on the computer
> rather than be handled by this dialog box.
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

> That makes perfect sense when I read it but
> still leaves me wondering then how and when
> to use IFF

IIF is an SQL function that it just allows you to return two different values
depending on the condition. I'm guessing in the case of using it in Olifant
filter where the final result must be a Boolean, IIF has little use: you can
probably use normal AND and OR more easily in most cases.

Some rare cases where it may be used would be when you want to transform a
result based on a condition, and then use that result on another condition. I
cannot come up with a concrete example at the top of my head (or at least one
you can't do with just OR/AND).

It's mostly available because it's part of the available SQL functions.

Cheers,
-yves

Piotr is right: that's the .NET Rainbow.
Try the newer Java version.

This said, tt should still work properly.
But it has some short-comings with 64-bit machine.
This has to do with the default name of the program folder not being the same in
64-bit Windows machines

The solution is likely here:
http://tech.groups.yahoo.com/group/okapitools/message/657

cheers,
-yves



-----Original Message-----
From: okapitools@yahoogroups.com [mailto:okapitools@yahoogroups.com] On Behalf
Of SafeTex
Sent: Friday, May 11, 2012 9:34 AM
To: okapitools@yahoogroups.com
Subject: [okapitools] Rainbow won't run

Hello

I wanted to have a little look at Rainbow today which I downloaded about a month
ago but it won't run

If I try to run it from Olifant, I get the type of message that makes me want to
make for the hills (see below)

If I click directly on the Rainbow.exe, nothing happens either

Any pointers please?

Thanks


See the end of this message for details on invoking just-in-time (JIT) debugging
instead of this dialog box.

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an
object.
    at Okapi.Library.Base.Routines.GetOkapiFolder()
    at Olifant.MainForm.m_miStartRainbow_Click(Object sender, EventArgs e)
    at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
    at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
    at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
    at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
    at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
    at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
    at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button,
Int32 clicks)
    at System.Windows.Forms.Control.WndProc(Message& m)
    at System.Windows.Forms.ToolStrip.WndProc(Message& m)
    at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
    at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
    at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr
wparam, IntPtr lparam)


************** Loaded Assemblies ************** mscorlib
     Assembly Version: 2.0.0.0
     Win32 Version: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
     CodeBase:
file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
----------------------------------------
Olifant
     Assembly Version: 3.0.8.0
     Win32 Version: 3.0.8.0
     CodeBase: file:///C:/Program%20Files%20(x86)/Okapi/Olifant/Olifant.exe
----------------------------------------
System.Windows.Forms
     Assembly Version: 2.0.0.0
     Win32 Version: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
     CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e\
089/System.Windows.Forms.dll
----------------------------------------
System
     Assembly Version: 2.0.0.0
     Win32 Version: 2.0.50727.5456 (Win7SP1GDR.050727-5400)
     CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
     Assembly Version: 2.0.0.0
     Win32 Version: 2.0.50727.5458 (Win7SP1GDR.050727-5400)
     CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/Sy\
stem.Drawing.dll
----------------------------------------
Okapi.Library.Base
     Assembly Version: 1.0.17.0
     Win32 Version: 1.0.17.0
     CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/Okapi.Library.Base/1.0.17.0__5e78ed90c17624\
66/Okapi.Library.Base.dll
----------------------------------------
Okapi.Library.Segmentation
     Assembly Version: 1.0.17.0
     Win32 Version: 1.0.17.0
     CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/Okapi.Library.Segmentation/1.0.17.0__77a2a0\
87340b0ec9/Okapi.Library.Segmentation.dll
----------------------------------------
Okapi.TM.Engine
     Assembly Version: 1.0.5.0
     Win32 Version: 1.0.5.0
     CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/Okapi.TM.Engine/1.0.5.0__a969eeed1cf92e4f/O\
kapi.TM.Engine.dll
----------------------------------------
System.Xml
     Assembly Version: 2.0.0.0
     Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
     CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System\
.Xml.dll
----------------------------------------
Okapi.Library.UI
     Assembly Version: 1.0.18.0
     Win32 Version: 1.0.18.0
     CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/Okapi.Library.UI/1.0.18.0__c3b51f7b3ca8b843\
/Okapi.Library.UI.dll
----------------------------------------
System.Data
     Assembly Version: 2.0.0.0
     Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400)
     CodeBase:
file:///C:/Windows/assembly/GAC_64/System.Data/2.0.0.0__b77a5c561934e089/System.\
Data.dll
----------------------------------------

************** JIT Debugging ************** To enable just-in-time (JIT)
debugging, the .config file for this application or computer (machine.config)
must have the jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging enabled.

For example:

<configuration>
     <system.windows.forms jitDebugging="true" /> </configuration>

When JIT debugging is enabled, any unhandled exception will be sent to the JIT
debugger registered on the computer rather than be handled by this dialog box.





------------------------------------

Yahoo! Groups Links

Hi,

I'm often translating MS Word documents, where the formatting causes my
translation environment tool to insert inline codes in several segments.

To remove these codes I use Olifant 3.0.8 (Okapi Tools Release 22). In some
cases, there could for example be 50 segments with complicated codes.

If I select, say, 5 such segments at once and execute Entries/Remove codes, I
will receive this error message:

Object reference not set to an instance of an object.
    at Olifant.MainForm.RemoveCodes()
Olifant v3.0.8.0; CC=Finnish (Finland); IL=Finnish; OS=Microsoft Windows NT
6.1.7601 Service Pack 1

Occasionally, Olifant has even crashed when trying to remove lots of codes.

Would there be any way to avoid this error? Removing codes manually one segment
at a time is rather time consuming when there are lots of inline coded segments
in the TM.

Is there any scripting functionality in Olifant?

Thanks in advance for any help with this issue!

Best regards,
Arne

Hi Arne,

> If I select, say, 5 such segments at
> once and execute Entries/Remove codes, I will
> receive this error message:
> ...
> Occasionally, Olifant has even crashed when
> trying to remove lots of codes.

I've tried to reproduce the problem, but without success.
Maybe if I try on one of your files, I could reproduce it?
And guess what is the issue.

Note that Olifant .NET is unlikely to be fixed as we are actively working on the
Java version. But still: knowing understanding the possible bug would help
making sure it's not in the new version.


> Is there any scripting functionality in Olifant?

No.

Cheers,
-yves

All,

I would like to remove segments from TMX if
- souce = target
- if len(source) = 10*len(target)
- if souce or target does not contain alphanumeric characters
- ...

Things I used to do with Olifant.  If this possible to do this in an
Okapi pipeline?

thanks

gert

Do people know about powertools.codeplex.com? This project has good interesting
tools for working with docx files etc, including ones which can combine those
pesky "runs" which generate tags ad nauseum. Perhaps there's something useful
here, although it's all .NET stuff.
--
Bob

Hi Gert,

> I would like to remove segments from TMX if
> - souce = target
> - if len(source) = 10*len(target)
> - if souce or target does not contain alphanumeric characters
> - ...
> Things I used to do with Olifant.  If this possible
> to do this in an Okapi pipeline?

Not in any way I can think of I'm afraid.

Cheers,
-ys

We've been developing a proof of concept which will allow XLIFF round-tripping
via a Rainbow Translation Kit from and to a DOCX (via Tikal extract & merge).

So far, all of our tests have been successful and we're very pleased with the
Okapi tools.

The next phase (now that we've established the round-trip) is to put
placeholders in the XLIFF (i.e. mark each of the mrk or trans-unit) and extract
the target text for translation in an external database (used by a proprietary
front-end editor) and then merge those results back into XLIFF before the final
merge back to DOCX.

My very first idea was to create JAXB objects, unmarshal the XLIFF, manipulate
the objects in memory and marshal them again.  However, I saw significant
downside to this (i.e. Okapi already has XLIFF (un)marshalling in some fashion
and our XML marshalling would have to match Okapi's exactly for the final merge
to work properly).

This has brought me into the world of filters, pipelines and steps.  However,
I'm not confident that we're taking the correct approach.

Initially, I searched for a (series of) step(s) which could accomplish this
task.  I could not find any Steps packaged into Okapi to perform such a task. 
Did I miss something?

Next I considered creating a pipeline that takes the original xliff and then
write out another XLIFF using XLIFFWriter to override writeTextUnit() and write
out placeholders instead of some portions of text.

However, given that the full signature to writeStartFile() is private, I'm not
confident in this approach either.

I have a feeling that we've missed something obvious, so my apologies in advance
if there's some documentation which covers these topics ... but any guidance
(even a "go read this") would be most welcome.

Thanks...
jz

Hi Jacob,

> The next phase (now that we've established the
> round-trip) is to put placeholders in the XLIFF
> (i.e. mark each of the mrk or trans-unit) ...
> ... then merge those results back into XLIFF
> before the final merge back to DOCX.

It sounds like you could streamline your process if you are able to write some
Java code.

You may be able to write a step that just takes filter events as input and
populate your database. One of the types of events in TEXT_UNIT. And it contains
basically a <trans-unit>. You can access all segments from there.

Then you could have another step that takes also filter event as input and
replaces (or creates) the target segments with your translation from the
database.

You would have to make sure the text units are segmented the same way when they
get to your steps.

Having your own steps to put/get the data into/from your system would allow you
to be very flexible. For example have pipelines like this:

= Raw documents to filter events (docx as input)
+ segmentation
+ leveraging (if needed)
+ Your step1 to copy source/(target if needed) in your database


= Raw documents to filter events (docx as input)
+ segmentation (must be the same as above)
+ Your step2 to copy your translation back into the events
+ filter events to raw document (merges back)

See the example code in the distribution. It has a few basic example of steps.

Steps can be package as plugins. Actually it's nothing more than a jar of your
steps, and the class-path set to point to any dependencies your jar has.

You can drop the plugins into the a folder where Rainbow looks for plugins and
that make them available along with all the default ones.

We're working on a set of Trados-specific steps in this branch:
http://code.google.com/p/okapi/source/list?name=winsteps

You can see the snapshots of the plugin here:
http://okapi.opentag.com/snapshots/plugins/

If you think further you can also see your database as another input format. You
could write your own filter for your database: that would open your data to be
processed by any steps and merge back.

There is several pages explaining some of the low-level thinsg here:
http://okapi.opentag.com/devguide/index.html
There are not completely up-to-date I'm afraid, but they should get you to see
the overall principles of the filter events.

Cheers,
-yves

PS: Just FYI, writing your own steps is certainly more complex than just using
them, so you may want your ideas/questions exposed to more Okapi developers. A
few are lurking in this list, but most people writing Okapi-related code are in
the developers list here: http://groups.google.com/group/okapi-devel



-----Original Message-----
From: okapitools@yahoogroups.com [mailto:okapitools@yahoogroups.com] On Behalf
Of jeztrans
Sent: Monday, May 14, 2012 7:04 AM
To: okapitools@yahoogroups.com
Subject: [okapitools] Basic Guidance - XLIFF Roundtripping and Proprietary
Editor

We've been developing a proof of concept which will allow XLIFF round-tripping
via a Rainbow Translation Kit from and to a DOCX (via Tikal extract & merge).

So far, all of our tests have been successful and we're very pleased with the
Okapi tools.

The next phase (now that we've established the round-trip) is to put
placeholders in the XLIFF (i.e. mark each of the mrk or trans-unit) and extract
the target text for translation in an external database (used by a proprietary
front-end editor) and then merge those results back into XLIFF before the final
merge back to DOCX.

My very first idea was to create JAXB objects, unmarshal the XLIFF, manipulate
the objects in memory and marshal them again.  However, I saw significant
downside to this (i.e. Okapi already has XLIFF (un)marshalling in some fashion
and our XML marshalling would have to match Okapi's exactly for the final merge
to work properly).

This has brought me into the world of filters, pipelines and steps.  However,
I'm not confident that we're taking the correct approach.

Initially, I searched for a (series of) step(s) which could accomplish this
task.  I could not find any Steps packaged into Okapi to perform such a task. 
Did I miss something?

Next I considered creating a pipeline that takes the original xliff and then
write out another XLIFF using XLIFFWriter to override writeTextUnit() and write
out placeholders instead of some portions of text.

However, given that the full signature to writeStartFile() is private, I'm not
confident in this approach either.

I have a feeling that we've missed something obvious, so my apologies in advance
if there's some documentation which covers these topics ... but any guidance
(even a "go read this") would be most welcome.

Thanks...
jz



------------------------------------

Yahoo! Groups Links

Hi,

I'm creating a translation kit from an .ODT file. At first, I wanted to create a
Transifex project, but for some reason I can't connect to the server (I'm on a
free plan). I get a 403 error, so something is wrong with the authentication.
Actually, I don't have a project ID, only the so-called "slug".

Anyway, after that I tried to convert the .ODT to XLIFF and to .PO. Success.
However, the segments are not segmented according to a SRX I've input in the
Segmentation step. I uploaded this file and set "Overwrite existing segmentation
(resegment)", but to no effect.

What am I doing wrong?

Thanks for your help

Marco

Hi Marco,

Let's separate the two issues.

I'll check the Transifex package: they may have updated their API.
For login you should have a username and a password.
And the name of the project (the 'slug' I guess).
I'll check all that.

> Anyway, after that I tried to convert the .ODT to XLIFF
> and to .PO. Success. However, the segments are not
> segmented according to a SRX I've input in the
> Segmentation step. I uploaded this file and set
> "Overwrite existing segmentation (resegment)", but
> to no effect.

What steps did you use?
Did you use the pre-define pipeline "Translation Kit Creation"?
"convert ODT to XLIFF and to PO" sounds strange. Why not to PO directly?

Cheers,
-ys

Marco,

Actually regarding the segmentation:

We don't support segmentation with PO files. PO files are not designed for
representing segmented content. Technically we could try to represent one
segment per 'msgstr' but then the translator would have no way to
join/split/correct any incorrect segment.

See http://www.opentag.com/okapi/wiki/index.php?title=Rainbow_TKit_-_PO_Package

I think there is some segmentation support in the Translate Toolkit that may
help a bit: See http://translate.sourceforge.net/wiki/toolkit/posegment but the
doc says the tool cannot be used to re-join the segments.

-yves


-----Original Message-----
From: Yves Savourel [mailto:yves@...]
Sent: Tuesday, May 15, 2012 6:33 AM
To: 'okapitools@yahoogroups.com'
Subject: RE: [okapitools] Help with Transifex and segmentation needed

Hi Marco,

Let's separate the two issues.

I'll check the Transifex package: they may have updated their API.
For login you should have a username and a password.
And the name of the project (the 'slug' I guess).
I'll check all that.

> Anyway, after that I tried to convert the .ODT to XLIFF and to .PO.
> Success. However, the segments are not segmented according to a SRX
> I've input in the Segmentation step. I uploaded this file and set
> "Overwrite existing segmentation (resegment)", but to no effect.

What steps did you use?
Did you use the pre-define pipeline "Translation Kit Creation"?
"convert ODT to XLIFF and to PO" sounds strange. Why not to PO directly?

Cheers,
-ys

--- In okapitools@yahoogroups.com, "Yves Savourel" <yves@...> wrote:
>
> Hi Marco,
>
> Let's separate the two issues.
>
> I'll check the Transifex package: they may have updated their API.
> For login you should have a username and a password.
> And the name of the project (the 'slug' I guess).
> I'll check all that.
>
> > Anyway, after that I tried to convert the .ODT to XLIFF
> > and to .PO. Success. However, the segments are not
> > segmented according to a SRX I've input in the
> > Segmentation step. I uploaded this file and set
> > "Overwrite existing segmentation (resegment)", but
> > to no effect.
>
> What steps did you use?
> Did you use the pre-define pipeline "Translation Kit Creation"?
> "convert ODT to XLIFF and to PO" sounds strange. Why not to PO directly?

Sorry, I mean, I tried both: once to XLIFF and once to PO, just to verify if any
differences...
  :)

> Cheers,
> -ys
>

--- In okapitools@yahoogroups.com, "Yves Savourel" <yves@...> wrote:
>
> Marco,
>
> Actually regarding the segmentation:
>
> We don't support segmentation with PO files. PO files are not designed for
representing segmented content. Technically we could try to represent one
segment per 'msgstr' but then the translator would have no way to
join/split/correct any incorrect segment.

OK, didn't know that. So how do you create the PO from the ODT? I mean, how is
the original file split? According to which delimiters? Paragraph ends?

> See
http://www.opentag.com/okapi/wiki/index.php?title=Rainbow_TKit_-_PO_Package
>
> I think there is some segmentation support in the Translate Toolkit that may
help a bit: See http://translate.sourceforge.net/wiki/toolkit/posegment but the
doc says the tool cannot be used to re-join the segments.
>
> -yves

OK, but with XLIFF the segmentation step should work, shouldn't it?

Marco
>
> -----Original Message-----
> From: Yves Savourel [mailto:yves@...]
> Sent: Tuesday, May 15, 2012 6:33 AM
> To: 'okapitools@yahoogroups.com'
> Subject: RE: [okapitools] Help with Transifex and segmentation needed
>
> Hi Marco,
>
> Let's separate the two issues.
>
> I'll check the Transifex package: they may have updated their API.
> For login you should have a username and a password.
> And the name of the project (the 'slug' I guess).
> I'll check all that.
>
> > Anyway, after that I tried to convert the .ODT to XLIFF and to .PO.
> > Success. However, the segments are not segmented according to a SRX
> > I've input in the Segmentation step. I uploaded this file and set
> > "Overwrite existing segmentation (resegment)", but to no effect.
>
> What steps did you use?
> Did you use the pre-define pipeline "Translation Kit Creation"?
> "convert ODT to XLIFF and to PO" sounds strange. Why not to PO directly?
>
> Cheers,
> -ys
>

> ...I tried both: once to XLIFF and once to PO,
> just to verify if any differences...

Ah OK :)

Then the XLIFF output should be segmented.

If it's not, maybe the issue is on the segmentation rules. I assume you used the
default ones that are in Okapi's /config sub-directory. Those should work.

Cheers,
-ys

> ...So how do you create the PO from the ODT?
> I mean, how is the original file split?
> According to which delimiters? Paragraph ends?

Yes per paragraph for ODT.
Technically it's per "text unit" which is decided by each filter. Generally that
corresponds to "paragraphs" like for ODT. In XLIFF that's the content of a
<trans-unit>.

-ys

Thanks, Yves.  Response inline.

> It sounds like you could streamline your process if you are able to write some
Java code.

Yes, I should have mentioned that up front.  Java's not a problem and I was
expecting to do so.

> You may be able to write a step that just takes filter events as input and
populate your database. One of the types of events in TEXT_UNIT. And it contains
basically a <trans-unit>. You can access all segments from there.

On your advice, I've attempted this.  Preliminary results are positive.  I can
get the events, etc. and believe I understand the dynamics around the MARKER
characters inserted into the TextFragment.codedText.

> Then you could have another step that takes also filter event as input and
replaces (or creates) the target segments with your translation from the
database.
>
> You would have to make sure the text units are segmented the same way when
they get to your steps.
>
> Having your own steps to put/get the data into/from your system would allow
you to be very flexible. For example have pipelines like this:
>
> = Raw documents to filter events (docx as input)
> + segmentation
> + leveraging (if needed)
> + Your step1 to copy source/(target if needed) in your database
>
>
> = Raw documents to filter events (docx as input)
> + segmentation (must be the same as above)
> + Your step2 to copy your translation back into the events
> + filter events to raw document (merges back)
>
That's a very interesting approach.  I thought we'd have to write to XLIFF with
placeholders and then re-serialize the XLIFF before replacing the placeholders
in the text with the translated segements from the Database.  Now that I've
played with the Steps, etc., I see the wisdom in this approach.  Since we don't
use it in the translation process at all, it removes the need for generating an
XLIFF file at all.  I'll keep pushing in this direction.

> There is several pages explaining some of the low-level thinsg here:
> http://okapi.opentag.com/devguide/index.html
> There are not completely up-to-date I'm afraid, but they should get you to see
the overall principles of the filter events.
>
That was a very helpful pointer to some foundational concepts. Thanks.

>
> PS: Just FYI, writing your own steps is certainly more complex than just using
them, so you may want your ideas/questions exposed to more Okapi developers. A
few are lurking in this list, but most people writing Okapi-related code are in
the developers list here: http://groups.google.com/group/okapi-devel
>
>
Thanks for the tip.  Are you suggesting that the -devel list is ok receiving
messages from framework users (I had assumed it would only be for framework
authors)?

>
> -----Original Message-----
> From: okapitools@yahoogroups.com [mailto:okapitools@yahoogroups.com] On Behalf
Of jeztrans
> Sent: Monday, May 14, 2012 7:04 AM
> To: okapitools@yahoogroups.com
> Subject: [okapitools] Basic Guidance - XLIFF Roundtripping and Proprietary
Editor
>
> We've been developing a proof of concept which will allow XLIFF round-tripping
via a Rainbow Translation Kit from and to a DOCX (via Tikal extract & merge).
>
> So far, all of our tests have been successful and we're very pleased with the
Okapi tools.
>
> The next phase (now that we've established the round-trip) is to put
placeholders in the XLIFF (i.e. mark each of the mrk or trans-unit) and extract
the target text for translation in an external database (used by a proprietary
front-end editor) and then merge those results back into XLIFF before the final
merge back to DOCX.
>
> My very first idea was to create JAXB objects, unmarshal the XLIFF, manipulate
the objects in memory and marshal them again.  However, I saw significant
downside to this (i.e. Okapi already has XLIFF (un)marshalling in some fashion
and our XML marshalling would have to match Okapi's exactly for the final merge
to work properly).
>
> This has brought me into the world of filters, pipelines and steps.  However,
I'm not confident that we're taking the correct approach.
>
> Initially, I searched for a (series of) step(s) which could accomplish this
task.  I could not find any Steps packaged into Okapi to perform such a task. 
Did I miss something?
>
> Next I considered creating a pipeline that takes the original xliff and then
write out another XLIFF using XLIFFWriter to override writeTextUnit() and write
out placeholders instead of some portions of text.
>
> However, given that the full signature to writeStartFile() is private, I'm not
confident in this approach either.
>
> I have a feeling that we've missed something obvious, so my apologies in
advance if there's some documentation which covers these topics ... but any
guidance (even a "go read this") would be most welcome.
>
> Thanks...
> jz
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>

Hello

I'm using Ratel to try out some segmentation rules but not with much success

Ok, I know I'm useless on this sort of thing but the help pages are not abundant
with examples

I've been on a number of sites that speak about different 'flavors' of regular
expressions and I wouldn't be surprised if this is my problem

Anyway, I noticed today a remark from Yves

"If it's not, maybe the issue is on the segmentation rules. I assume you used
the
default ones that are in Okapi's /config sub-directory. Those should work."

Could Yves or someone elaborate on this? Where are these rules to see?
How can I load them ? To they work with Ratel?

Thanks in advance as always

> Could Yves or someone elaborate on this? Where are these rules to see?
> How can I load them ?

Hi, I would suggest to start with the sample rules in Ratel itself (File/New
With Sample Default Rules) and see how the "Mr. Holmes is from the U.K. ..."
line is split into chunks in square brackets in the grey memo. You can place
your sample text in place of "Mr. Holmes..."

Sergei

Hi Jacob,

>> ... A few are lurking in this list, but most people
>> writing Okapi-related code are in the developers list
>> here:
>> http://groups.google.com/group/okapi-devel
>
> Thanks for the tip.  Are you suggesting that the -devel
> list is ok receiving messages from framework users
> (I had assumed it would only be for framework authors)?

The 'okapitools' list is mostly for users of the tools (like Rainbow, Olifant,
etc.) and the 'okapi-devl' list is mostly for the developers working on the
code, but it serves also for contributors, and people working directly with the
code of the framework.

There are no strict rules, we just try to not bore end-users with too many
programming-related topics :)

Cheers,
-yves

Attached please find the default segmentation rules from Okapi
segmentation resources. You can load them in Ratel with File/Open.