Remove the dylib. As Didier said earlier.
And run OmegaT without it.


On 20 nov. 2009, at 02:10, dragomir_k wrote:

> After some googling, the problem might be in Mac OS X 10.4 Tiger, i.e. the
newest applications written specifically just for Leopard 10.5, and not as well
for the recent 10.4. version, produce the said error, as from the quoted log:
>
> Link (dyld) error:
>
> Symbol not found: _clock$UNIX2003
> Referenced from:
/Applications/OmegaT/OmegaT.app/Contents/Resources/Java/native/libhunspell.dylib
> Expected in: /usr/lib/libSystem.B.dylib

Jean-Christophe Helary (JA/EN > FR)
------------------------------------
http://mac4translators.blogspot.com/
http://twitter.com/brandelune
http://www.doublet.jp

In most cases, the third match percentage seems to be much more accurate and
less simplistic than the first, and yet it is the first that is used to decide
whether to insert a fuzzy match into the target segment. Could this be changed
easily, I wonder?
Best regards
Kerry

[Non-text portions of this message have been removed]

Hi all,

Removing one hand from the keyboard to use the mouse is always a loss of time,
and so I have some remarks about OmT's keyboard management, which IMHO could
still be improved.

1. Navigating with the keyboard between the source and the target for the
current segment is handy to paste parts of source text (e.g. product names). It
is currently impossible to use the keyboard to go up to the source when editing
the target, while the reverse is OK.

2. Moreover keyboard edition commands (move, select) do not work within the
source segment ? We are stuck to the mouse again.

3. Adding a SHIFT Return in addition to CTRL R (replace with match) would
improve speed.

4. I didn't manage to have the match selection shortcuts CTRL-1, CTRL-2, etc.
work with my azerty kb.

Cheers,

AO

-----Original Message-----
>From: OmegaT@yahoogroups.com [mailto:OmegaT@yahoogroups.com]On Behalf Of
Kerry Swatridge
>Sent: Friday, November 20, 2009 12:44 PM
>To: OmegaT@yahoogroups.com
>Subject: [OmT] Match percentages
>
>In most cases, the third match percentage seems to be much more accurate
and less simplistic than the first,

I would have wrote exactly the contrary.
With the third, a segments with 30 tags in common and not a single word in
common is preferred to a segment with all the words in common and no common
tags.
I wouldn't call that accurate and complex.

Not to mention that the first percentage can take stemming into account,
which further improves the semantic value of the matching.

>and yet it is the first that is used to decide whether to insert a fuzzy
match into the target segment. Could this be changed easily, I wonder?

Easily as "it could be hard coded easily", I suppose yes.

Easily as "it should configurable", the answer is that anything configurable
takes time.

Look at
- auto insert match based on selectable %
http://sourceforge.net/support/tracker.php?aid=2882151

Jean-Christophe's definition of noise is interesting.

That said, changing the percentage for this reason would be a work around,
in my opinion.
The real thing to do is to have the insertion try and match the tags in the
actual segment.

Didier

-----Original Message-----
>From: OmegaT@yahoogroups.com [mailto:OmegaT@yahoogroups.com]On Behalf Of
alxobr
>Sent: Friday, November 20, 2009 9:55 PM
>To: OmegaT@yahoogroups.com
>Subject: [OmT] Some remarks about keyboard usage

>3. Adding a SHIFT Return in addition to CTRL R (replace with match) would
improve speed.

Shift + Return is already used (to create a Return inside the segment).

>4. I didn't manage to have the match selection shortcuts CTRL-1, CTRL-2,
etc. work with my azerty kb.

Works here, under Windows XP, Knoppix, Debian and PC Linux OS, both on the
desktop machine and on the laptop (Debian not tested on the laptop).

There must be something specific to your case.

Didier

-----Original Message-----
>From: OmegaT@yahoogroups.com [mailto:OmegaT@yahoogroups.com]On Behalf Of
Kerry Swatridge
>Sent: Tuesday, November 17, 2009 3:20 PM
>To: OmegaT@yahoogroups.com
>Subject: [OmT] File filter filename patterns
>
>I have set the Translated Filename Pattern for MS Open XML files to
"${nameOnly}-en.${extension}". I want to do so for docx, xlsx and pptx, but
OmegatT only seems to remember for docx and xlsx. If I change the pptx
setting, it seems to revert straightaway to ${filename}.

No idea, it works here.

Perhaps some of the values are corrupted (for whatever reasons).
Have you tried to click on Default values (in the Open XML filter)?

By the way (supposing you sometimes translate to something other than "en"),
you can use
${nameOnly}-${targetLanguageCode}.${extension}

Didier

--- In OmegaT@yahoogroups.com, "Didier Briel" <d.briel@...> wrote:
>
> -----Original Message-----
> >From: OmegaT@yahoogroups.com [mailto:OmegaT@yahoogroups.com]On Behalf Of
> alxobr
> >3. Adding a SHIFT Return in addition to CTRL R (replace with match) would
improve speed.
>
> Shift + Return is already used (to create a Return inside the segment).
So maybe CTRL + Return...

> >4. I didn't manage to have the match selection shortcuts CTRL-1, CTRL-2,
> etc. work with my azerty kb.
>
> Works here, under Windows XP, Knoppix, Debian and PC Linux OS, both on the
> desktop machine and on the laptop (Debian not tested on the laptop).
>
> There must be something specific to your case.
Do you press the shift key to get them ?

AO

-----Original Message-----
>From: OmegaT@yahoogroups.com [mailto:OmegaT@yahoogroups.com]On Behalf Of
alxobr
>Sent: Saturday, November 21, 2009 11:08 AM
>To: OmegaT@yahoogroups.com
>Subject: Re: [OmT] Some remarks about keyboard usage

>> >4. I didn't manage to have the match selection shortcuts CTRL-1, CTRL-2,
>> etc. work with my azerty kb.
>>
>> Works here, under Windows XP, Knoppix, Debian and PC Linux OS, both on
the
>> desktop machine and on the laptop (Debian not tested on the laptop).
>>
>> There must be something specific to your case.
>Do you press the shift key to get them ?

No.

On an AZERTY keyboard, you mustn't press shift to use Ctrl+1, 2, etc.

So, actually, the shortcuts are
Ctrl + &
Ctrl + �
Ctrl + "
Ctrl + '
Ctrl + (

Didier

alxobr wrote:

> 1. Navigating with the keyboard between the source and the target for
> the current segment is handy to paste parts of source text (e.g.
> product names). It is currently impossible to use the keyboard to go
> up to the source when editing the target, while the reverse is OK.

+1

> 2. Moreover keyboard edition commands (move, select) do not work
> within the source segment ? We are stuck to the mouse again.

+1

> 3. Adding a SHIFT Return in addition to CTRL R (replace with match)
> would improve speed.

Wasn't it possible to change OmegaT's keyboard shortcuts?  I looked in
the manual but could not find anything on it.

Samuel

On 21 nov. 2009, at 23:13, Samuel Murray (Krugersdorp) wrote:

>> 3. Adding a SHIFT Return in addition to CTRL R (replace with match)
>> would improve speed.
>
> Wasn't it possible to change OmegaT's keyboard shortcuts?  I looked in
> the manual but could not find anything on it.

Documentation bug. The keyboard shortcuts are indeed configurable.





Jean-Christophe Helary (JA/EN > FR)
------------------------------------
http://mac4translators.blogspot.com/
http://twitter.com/brandelune
http://www.doublet.jp

--- In OmegaT@yahoogroups.com, "alxobr" <alxobr@...> wrote:

> 1. Navigating with the keyboard between the source and the target for the
current segment is handy to paste parts of source text (e.g. *product names*).
and TAGS !!

If you click Open, - even with the mouse ;-) - in the "Import Source files..."
dialog, rather than double-clicking on the directory name,
then all the files in the directory are imported. This is not standard and IMHO
quite weird.

Cheers,

AO


--- In OmegaT@yahoogroups.com, "alxobr" <alxobr@...> wrote:
>
> Hi all,
>
> I tried to hit return in order to browse to the new file's location and OmegaT
started a tremendous disk activity  I had to kill the process after several
minutes and when I reopened it I saw that there was a new file : boot.ini in the
root dir of my Windows partition ... with 3 segments to translate ;-)
> It would most probably have tried to load  *all the files* of the directory
hadn't I stopped it.
> This does not seem to be a java issue since I can browse with the return key
to open a project for instance
>
> Cheers,
>
> AO
>

-----Original Message-----
>From: OmegaT@yahoogroups.com [mailto:OmegaT@yahoogroups.com]On Behalf Of
alxobr
>Sent: Saturday, November 21, 2009 10:11 PM
>To: OmegaT@yahoogroups.com
>Subject: [OmT] Re: Some remarks about keyboard usage
>
>
>--- In OmegaT@yahoogroups.com, "alxobr" <alxobr@...> wrote:
>
>> 1. Navigating with the keyboard between the source and the target for the
current segment is handy to paste parts of source text (e.g. *product
names*).
>and TAGS !!

A matter of taste, but if you use "Copy source text" in Editing Behaviour,
you don't even have to paste, because it's already there.

Didier

> A matter of taste, but if you use "Copy source text" in Editing
> Behaviour,
> you don't even have to paste, because it's already there.

That's right, though the single easiest way to copy over parts of the
source segment has got to be the way it works in Wordfast's Word plugin.
Just typing the first one or two letters and then TAB, which auto-fills
the rest like in a Linux/UNIX command line. That was the single best
thing in Wordfast and the only thing I slighly miss since working with
OmegaT.

However, OmegaT works great for me, thanks for this great application!

Best,
Dan

From: Didier Briel
>>In most cases, the third match percentage seems to be much more accurate
>>and less simplistic than the first,

>I would have wrote exactly the contrary.
>With the third, a segments with 30 tags in common and not a single word in
>common is preferred to a segment with all the words in common and no common
>tags.
>I wouldn't call that accurate and complex.

Ok, I admit my "most cases" wasn't very scientific. I'll try and observe
further.
Kerry

Thanks Didier. I tried resetting to the defaults in the Open XML filter, and
then re-entering my preferred pattern, and clicking on OK. When I then click
on Edit again for Open XML files, once again the *.doc? and *.xls? patterns
are retained, but the *.ppt? pattern has been reset to ${filename}.
Kerry
----- Original Message -----
From: Didier Briel
To: OmegaT@yahoogroups.com
Sent: Saturday, November 21, 2009 9:35 AM
Subject: RE: [OmT] File filter filename patterns



-----Original Message-----
>From: OmegaT@yahoogroups.com [mailto:OmegaT@yahoogroups.com]On Behalf Of
Kerry Swatridge
>Sent: Tuesday, November 17, 2009 3:20 PM
>To: OmegaT@yahoogroups.com
>Subject: [OmT] File filter filename patterns
>
>I have set the Translated Filename Pattern for MS Open XML files to
"${nameOnly}-en.${extension}". I want to do so for docx, xlsx and pptx, but
OmegatT only seems to remember for docx and xlsx. If I change the pptx
setting, it seems to revert straightaway to ${filename}.

No idea, it works here.

Perhaps some of the values are corrupted (for whatever reasons).
Have you tried to click on Default values (in the Open XML filter)?

By the way (supposing you sometimes translate to something other than "en"),
you can use
${nameOnly}-${targetLanguageCode}.${extension}

Didier

Dear,

Does anyone have any experience in converting Star Transit files (_EXTR_, txf or
pxf) into a format, understandable by OmegaT?

Is this possible with Okapi?

Althought Star Transit Sattelite seems not a bad application, it keeps crashing
on me, and that's something I cannot say from OmegaT.

Any help or hints are appreciated.

Regards,

Nicolas Severyns

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Klausgena schrieb:
> Dear,
>
> Does anyone have any experience in converting Star Transit files
> (_EXTR_, txf or pxf) into a format, understandable by OmegaT?
>
Not really experience...
pxf and txf are zip-files. It should be possible to create a txf file
with external tool. The txf file contains the project specific
dictionary, a project definition file (.prj) and the file(s) with the
translated segments. The latter are UTF-16 coded tagged text files. They
are declared as xml version="1.0", but they contain some binary trash. I
have already succeeded to make some minor changes in such a file with a
text editor.
You can just try to translate the files with the extension according to
your target language with OmegaT. Then put them together with the
dictionary and the prj file from your pxf file in a zip file, give it
the extension .txf
If you have imported the pxf file, you can put the translated files in
the according folder of your Transit project, try to open the project
and use Transit to make the txf file.
I have no clue if it will work, just some ideas.

Regards
Karsten

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksL3I4ACgkQGlm9zmKHESFLUwCgwL5rQnOqXIgbkvv0QiTuMub8
wtAAnRFftPgwOsOcIAfM0f7PAq3PQpXI
=4+/S
-----END PGP SIGNATURE-----

-----Original Message-----
>From: OmegaT@yahoogroups.com [mailto:OmegaT@yahoogroups.com]On Behalf Of
Kerry Swatridge
>Sent: Monday, November 23, 2009 11:34 AM
>To: OmegaT@yahoogroups.com
>Subject: Re: [OmT] File filter filename patterns

>Thanks Didier. I tried resetting to the defaults in the Open XML filter,
and
>then re-entering my preferred pattern, and clicking on OK. When I then
click
>on Edit again for Open XML files, once again the *.doc? and *.xls? patterns
>are retained, but the *.ppt? pattern has been reset to ${filename}.

Sorry, I just tried again, and I cannot reproduce it.

If someone else can, perhaps we would be able to find a pattern.

Didier

Klausgena wrote:

> Does anyone have any experience in converting Star Transit files
> (_EXTR_, txf or pxf) into a format, understandable by OmegaT?

Thanks for the very interesting question.  I played around and was able
to translate a PXF file in OmegaT.  But you need balls.  My method of
testing whether a conversion worked is to see if I can open the file in
its original application with any problems.

I'm using Windows XP SP2, and OmegaT 2.1.0.  I also use Babelpad 1.10.3
and 7-zip 4.65.  Finally, a nice program to have is Taskill 1.02 to kill
Transit when it hangs.  My version of Transit Satellite is PE 3.0.

http://members.ozemail.com.au/~nulifetv/freezip/freeware/
http://www.babelstone.co.uk/Software/BabelPad.html
http://www.7-zip.org/

First, you must realise that the PXF file is a zip file.  Unzip it
(using 7-zip, for example).  Inside it, you'll find files with your two
language codes (in my case, file.ENG and file.AFK).  If the PXF file is
untranslated, the target text file will contain the translatable text in
the source language.  In my case, I translate from English to Afrikaans,
and this means that both the .ENG and the .AFK files contain the English
text before I start translating.

Next, open the .AFK file (your target file) in Babelpad.  Create
segmentation rules for "TXT" files in OmegaT by copying/pasting the
character before and after the source text in the .AFK file.  So the
segmentation rules will be:

Break: yes
Before: (one little square box)
After: . (fullstop)

Break: yes
Before: . (fullstop)
After: (other little square box)

Add .AFK to your "Text files" filter, or create a new one.  The source
encoding is UTF-16 LE and so is the target encoding (don't use "Auto").
   I prefer to set up the paragraphisation to "Never", but it's your
choice.  Let me know if you don't understand this.

Put the .AFK files in /source/ and start translating.  OmegaT will
display a lot of junk, which you must skip.  You'll see what to
translate, so translate it.  Then, create your target files.

Open the .AFK file from the /target/ folder in Babelpad, go Ctrl+Shift+S
(which is "Save as") and tick the "BOM" item before saving it.  OmegaT
does not add a BOM to UTF-16 LE files even if the source file has a BOM.
   The BOM is not compulsory in UTF-16 LE but it is quite common, and
Transit won't work without it.

Now rezip the unzipped PXF file, but make sure that the .AFK files etc
are in the root of the zip file (in other words, not inside a folder
with the same name as the zip file).  What I do, is to go into the
folder and then select everything and right-click and select "zip",
which automatically creates a zip file with the same name as the folder.
   Rename the .zip file to .pxf, and open it in Transit PE.

That's it.

Samuel

Samuel Murray (Krugersdorp) wrote:

> Klausgena wrote:

>> Does anyone have any experience in converting Star Transit files
>> (_EXTR_, txf or pxf) into a format, understandable by OmegaT?

> I played around and was able
> to translate a PXF file in OmegaT.

Keep in mind that if you use my method, the user IDs for the translation
would still be the same as that of the source text, so it may be
necessary to "run through" all the segments in some or other way if it
is crucial for your client to have your user ID in the translation.

Samuel

Where can I find help to configure Omegat to use stardict dictionary?

Julian

Thanks everyone for the detailed answers.

I managed to open one of the files in Notepad++, made some changes, tried it in
Transit, it worked.
The only thing scaring me were those stupid squares in the files. I was
wondering what kind of encoding that could be, I'm glad to know it's UTF-16. On
the proz.com forum I read it should be XML-files, but they sure do not look like
that.

Dear Samuel, as for changing the ID and name of the person translating   each
segment, can't this be easily done by a find replace in the .AFK (.ENG,...)
file, were you replace the name of the translator of the source segments with
your name?

I was scared changing all those files would somehow break the database backend
of Transit, but apparently it doesn't.

Thanks,

Kind regards,

Nicolas Severyns

--- In OmegaT@yahoogroups.com, "Samuel Murray (Krugersdorp)" <leuce@...> wrote:
>
> Klausgena wrote:
>
> > Does anyone have any experience in converting Star Transit files
> > (_EXTR_, txf or pxf) into a format, understandable by OmegaT?
>
> Thanks for the very interesting question.  I played around and was able
> to translate a PXF file in OmegaT.  But you need balls.  My method of
> testing whether a conversion worked is to see if I can open the file in
> its original application with any problems.
>
> I'm using Windows XP SP2, and OmegaT 2.1.0.  I also use Babelpad 1.10.3
> and 7-zip 4.65.  Finally, a nice program to have is Taskill 1.02 to kill
> Transit when it hangs.  My version of Transit Satellite is PE 3.0.
>
> http://members.ozemail.com.au/~nulifetv/freezip/freeware/
> http://www.babelstone.co.uk/Software/BabelPad.html
> http://www.7-zip.org/
>
> First, you must realise that the PXF file is a zip file.  Unzip it
> (using 7-zip, for example).  Inside it, you'll find files with your two
> language codes (in my case, file.ENG and file.AFK).  If the PXF file is
> untranslated, the target text file will contain the translatable text in
> the source language.  In my case, I translate from English to Afrikaans,
> and this means that both the .ENG and the .AFK files contain the English
> text before I start translating.
>
> Next, open the .AFK file (your target file) in Babelpad.  Create
> segmentation rules for "TXT" files in OmegaT by copying/pasting the
> character before and after the source text in the .AFK file.  So the
> segmentation rules will be:
>
> Break: yes
> Before: (one little square box)
> After: . (fullstop)
>
> Break: yes
> Before: . (fullstop)
> After: (other little square box)
>
> Add .AFK to your "Text files" filter, or create a new one.  The source
> encoding is UTF-16 LE and so is the target encoding (don't use "Auto").
>   I prefer to set up the paragraphisation to "Never", but it's your
> choice.  Let me know if you don't understand this.
>
> Put the .AFK files in /source/ and start translating.  OmegaT will
> display a lot of junk, which you must skip.  You'll see what to
> translate, so translate it.  Then, create your target files.
>
> Open the .AFK file from the /target/ folder in Babelpad, go Ctrl+Shift+S
> (which is "Save as") and tick the "BOM" item before saving it.  OmegaT
> does not add a BOM to UTF-16 LE files even if the source file has a BOM.
>   The BOM is not compulsory in UTF-16 LE but it is quite common, and
> Transit won't work without it.
>
> Now rezip the unzipped PXF file, but make sure that the .AFK files etc
> are in the root of the zip file (in other words, not inside a folder
> with the same name as the zip file).  What I do, is to go into the
> folder and then select everything and right-click and select "zip",
> which automatically creates a zip file with the same name as the folder.
>   Rename the .zip file to .pxf, and open it in Transit PE.
>
> That's it.
>
> Samuel
>

--- In OmegaT@yahoogroups.com, "Klausgena" <klausgena@...> wrote:
>
> Dear,
>
> Does anyone have any experience in converting Star Transit files (_EXTR_, txf
or pxf) into a format, understandable by OmegaT?
>
> Is this possible with Okapi?
>
> Althought Star Transit Sattelite seems not a bad application, it keeps
crashing on me, and that's something I cannot say from OmegaT.
>
> Any help or hints are appreciated.
>
> Regards,
>
> Nicolas Severyns
>

The format of (unpacked) bilingual files is a little strange, because as far as
I can remember the source and target text pairs are tagged with binary (!)
record numbers, or something similarly crazy. I think PlusToyz converts star
Transit too - to TMX for instance, so that could help.

smo

2009/11/24 vivasandino <julianramon@...>
>
>
>
> Where can I find help to configure Omegat to use stardict dictionary?

In the Dictionaries section of the manual. Also search the archives of
this group for discussions on the topic.

Best regards,

Dmitri Gabinski

Klausgena wrote:

> As for changing the ID and name of the person
> translating each segment, can't this be easily done by a find
> replace in the .AFK (.ENG,...) file, were you replace the name of the
> translator of the source segments with your name?

I didn't try to do it.  I was hoping that it could be done by some
setting within Transit (eg "accept all" or "validate all" or something
like that).

Samuel

Thanks, Dimitri. It is almost impossible to find something using the search
facility in this group. It took me a lot to find out in the last beta of
OmegaT there was an updated version of the manual. In the previous versions
there was nothing about dictionaries. Even when I found the answer in the
new manual, my dictionary feature did not worked until I discovered by
myself in the omegat log that OmegaT could not use these files due to
permision restrictions (they were located in /usr/share/stardict/dic/) and
then, the only solution was to get root privileges to move the dictionaries
to my home directory and change the privileges there.

It took me a lot to do it, though. I think help information in the group
site, the OmegaT website and sourceforge is not very well organised and
there are too many versions, and maybe we can all work together to improve
our manual.

But thanks a lot for your answer!

Julian



2009/11/25 ������� ��������� <gdkbnx@...>

>
>
> 2009/11/24 vivasandino <julianramon@... <julianramon%40gmail.com>>
>
> >
> >
> >
> > Where can I find help to configure Omegat to use stardict dictionary?
>
> In the Dictionaries section of the manual. Also search the archives of
> this group for discussions on the topic.
>
> Best regards,
>
> Dmitri Gabinski
>
>


[Non-text portions of this message have been removed]

-----Original Message-----
>From: OmegaT@yahoogroups.com [mailto:OmegaT@yahoogroups.com]On Behalf Of
Julian Ram�n Guevara
>Sent: Wednesday, November 25, 2009 6:58 PM
>To: OmegaT@yahoogroups.com
>Subject: Re: [OmT] How to use dictionary feature?

>It took me a lot to find out in the last beta of
>OmegaT there was an updated version of the manual.

The updated manual is included in the stable version 2.0.5.

Didier Briel

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the OmegaT
group.

   File        : /2- Documentation/OmegaT_205_EN.pdf
   Uploaded by : smolejv <smolejv@...>
   Description : OmegaT 2.05 documentation EN as PDF

You can access this file at the URL:
http://groups.yahoo.com/group/OmegaT/files/2-%20Documentation/OmegaT_205_EN.pdf

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/forms/general.htmlfiles

Regards,

smolejv <smolejv@...>

....
> site, the OmegaT website and sourceforge is not very well organised and there
are too many versions, and maybe we can all work together to improve our manual.

Suggestions regarding the manual have always been welcome. Keep them coming!

Hint #1: since some time the documentation includes also the Cross Index
(xindex.html) and "dictionary" is among the entries.

Hint #2: there's a PDF version EN (with all links active) in the "Files"
section.

Regards
Vito