Re: CAT tool to translate Paradox database?

#1

if you're translating to a different language, you will most likely have to
change the Paradox language driver before you re-import the data to a
Paradox table.. and that is *not* something that you can do without Paradox
and/or the BDE..

--
Steven Green - Waldorf Maryland USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox

Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Sports Memorabilia and Trading Cards

"Jan Sundström" <jan.sundstrom (AT) sematix (DOT) se> wrote

Quote:

Hi all,

We're a translation agency, and have a prospective assignment to translate
a Paradox database.
The client tells us to do the translation in DB Commander. I've learnt
that
I can export the text of the database with DBC, translate it with a third
party CAT tool (Trados or similar), and re-import it again using DBC.

Is this the best way to do it, or can you recommend any other/better
method?

Thanks a lot in advance,

Jan

#2

maybe this doesn't apply to other platforms, but it must..

if I export an English Paradox database to text, then translate the text to
German, there will now be characters in the text that are unsupportable..
and, the date and number formats will change.. the re-import *must* be to a
completely different set of tables, with the proper language driver,
different indexes, etc..

and if the primary links are changed, yes that's a disaster.. however, if
the system is designed well, that part won't happen..

to be honest, my issue here is that if you do this for a living, you should
already be aware of these things..

--
Steven Green - Waldorf Maryland USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox

Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Sports Memorabilia and Trading Cards

"Jan Sundström" <jan.sundstrom (AT) sematix (DOT) se> wrote

Quote:

Thanks for the reply, Steven.

We will just deliver the translated database files to the end client, so
I'm confident that they will manage the settings and drivers at that
stage.

But my question is the export/import procedure while handling the Paradox
files in DBC.

DBC can dump the entire content of the database into TXT or XML files?!
I can translate the visible text with my CAT tool (Trados) and re-import
it with DBC.

Now the client is afraid that the links between the Paradox files will be
lost/corrupted. But AFAIK, the CAT tool keeps the integrity of the
database,
while only touching the readable text content.

Does it make sense?

/Jan

"Steven Green" <greens (AT) diamondsg (DOT) com> wrote:
if you're translating to a different language, you will most likely have
to
change the Paradox language driver before you re-import the data to a
Paradox table.. and that is *not* something that you can do without
Paradox

and/or the BDE..

--
Steven Green - Waldorf Maryland USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox

Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Sports Memorabilia and Trading Cards

"Jan Sundström" <jan.sundstrom (AT) sematix (DOT) se> wrote in message
news:44c63531 (AT) pnews (DOT) thedbcommunity.com...

Hi all,

We're a translation agency, and have a prospective assignment to
translate
a Paradox database.
The client tells us to do the translation in DB Commander. I've learnt

that
I can export the text of the database with DBC, translate it with a
third
party CAT tool (Trados or similar), and re-import it again using DBC.

Is this the best way to do it, or can you recommend any other/better
method?

Thanks a lot in advance,

Jan

#3

What Steve said. The translated data cannot be stuffed back into the
same files.

It's not a case of some generic format of data and some external
<thing> decides what to do with the bits in the table - the table
itself holds the instructions on what to do with its bits, and
depending on the source language, target language and table language,
stuffing the target language into the table will result in garbage.

Further, it's possible, depending on the development tool and
methodology, that just translating the data in the tables won't be
enough - mods will have to be made to the data-aware controls to allow
them to properly display the target language characters.

Simply put, software localization (which I did for a time) is not as
simple as translating the words.

Liz

"Jan Sundström" wrote:

Quote:

We will just deliver the translated database files to the end client, so
I'm confident that they will manage the settings and drivers at that stage.

#4

"Jan Sundström" wrote:

Quote:

Luckily, our assignment this time consists of pure translation.
If we just can assure that the extended chars shows up as intended, any other
localization issues that surface after re-import will have to be solved by
the end client.

Yes, well, the problem with that is that after re-import, the problem
can't be solved by the client, it's too late, the data in the table
will be garbage*. If you want them to have all the responsibility,
tell them to ensure that the source tables they give you support the
target language's characters.

If you want to know what table languages will support the target
language characters, tell us the target language(s).

* I suppose it's possible they could export it to text and import to a
different table, but I'm not even sure that would work, they may well
still have garbage after that.

Liz

#5

Quote:

If we just can assure that the extended chars shows up as intended, any
other localization issues that surface after re-import will have to be
solved by the end client.

repeating what Liz said, and what we've both said before.. NO!

--
Steven Green - Waldorf Maryland USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales - Corel CTech Paradox

Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Sports Memorabilia and Trading Cards

#6

Jan,

If the original tables support Finnish characters, they'll also
support all English characters and you've got no worries - just keep
the original table language so it supports the Finnish proper names
you plan to keep.

(Note: Nearly every table language, if not every table language,
supports English characters, it's just a question of what else it
might support.)

Liz

"Jan Sundström" wrote:

Quote:

Hi Liz,

Thanks for your helpful assistance.

We're supposed to translate from Finnish to English, so I hop we can avoid
trouble with extended chars. The only obstacles would be names containing
Ä, Ö, where we'd like to keep the original spelling. Worse comes to worst,
we would transcribe those chars to A, O instead.
I guess there's still a likelyhood to come up with garbage at re-import,
with all this precaution taken. I'll have to discuss the possibility of teh
end client preparing a new set of tables supporting English.

Best,

Jan

#7

Jan Sundström wrote:

Quote:

Hi all,

We're a translation agency, and have a prospective assignment to translate
a Paradox database.

Excuse my ignorance but what does it mean "to translate a database?". I
can imagine to translate the content of some fields (let's say "notes",
"description"...) but i cant imagine to translate a family name,a date,
a numeric field. If the database does not contain 37 tables with 221
fields it should not be so difficult with programming

Quote:

The client tells us to do the translation in DB Commander. I've learnt that
I can export the text of the database with DBC, translate it with a third
party CAT tool (Trados or similar), and re-import it again using DBC.

Is this the best way to do it, or can you recommend any other/better method?

Thanks a lot in advance,

Jan

#8

marco wrote:

Quote:

Excuse my ignorance but what does it mean "to translate a database?". I
can imagine to translate the content of some fields (let's say "notes",
"description"...) but i cant imagine to translate a family name,a date,
a numeric field. If the database does not contain 37 tables with 221
fields it should not be so difficult with programming

Marco, actually, this is usually done either on data in the database
which is displayed as part of the application (instructions, menu
option text, error messages, etc.) or on sample data used to demo the
system.

For sample data, names do get "translated" (proper term is
"localized") so that John Smith becomes Juan Valdez (or something) in
the target language. The goal is to make it look like the software
was created not for someone in the US, but for someone in Mexico or
Spain or Portugal or Brazil, etc. Location names are translated (New
York City becomes Milan), etc. Date and number formats are changed as
needed and even the values can be changed (e.g. the sample data might
have the price of milk at so many dollars for a gallon and this might
be translated into so many lira per liter (or litre, if you prefer)
<g>).

Depending on the budget, localization is specific to the geographic
target, both in the language used and the names of locations, things
and people - e.g. Brazilian portuguese and Portuguese, um, portuguese
are different; Generally Central/South American spanish and Spanish
spanish are translated differently, UK vs. US english, French french
vs. Canadian french...

HTH,

Liz

#9

Paradox.

Liz

"Jan Sundström" wrote:

Quote:

Does anyone of you guys have a different database editor that could handle
the export/import better???

#10

What does "choke" mean? Error messages?

"Jan Sundström" <jan.sundstrom (AT) semantix (DOT) se> wrote

Quote:

Hi Marco,

OK, sorry for the rough description.
Off course we're working on the content of the fields, not the database
coding
as such.

And what Liz pinned down as localization is correct.
But our assignment is ACTUAL translation of words, the localization is
outside
our job scope.

So the content in this case is a spare parts catalogue:
"Bolt 5mm, bolt 6mm, bolt 7mm. Nut 5mm, nut 6mm, nut 7mm."
All these terms have to be translated from Finnish into English.

The total word count is 350 000 words (30 files with a few thousands of
lines
each), so we'd very much like to export the content, translate it with our
CAT tool, and then reimport.

We've tried to export as csv files with DBC, that works fine. But DBC
chokes
on the re-import.

Does anyone of you guys have a different database editor that could handle
the export/import better???

Thanks a lot in advance,

Jan

marco <n_sp_hum_marco.foglia (AT) tucsoft (DOT) com> wrote:
Jan Sundström wrote:
Hi all,

We're a translation agency, and have a prospective assignment to
translate
a Paradox database.

Excuse my ignorance but what does it mean "to translate a database?". I

can imagine to translate the content of some fields (let's say "notes",

"description"...) but i cant imagine to translate a family name,a date,

a numeric field. If the database does not contain 37 tables with 221
fields it should not be so difficult with programming

The client tells us to do the translation in DB Commander. I've learnt
that
I can export the text of the database with DBC, translate it with a
third
party CAT tool (Trados or similar), and re-import it again using DBC.

Is this the best way to do it, or can you recommend any other/better
method?

Thanks a lot in advance,

Jan