Mobile menu

Pages in topic:   [1 2] >
How to translate an MS Access file?
Thread poster: Edwal Rospigliosi

Edwal Rospigliosi  Identity Verified
Spain
Local time: 13:12
English to Spanish
+ ...
Jan 14, 2008

Hi

I have an Access (.mdb) file to translate. Is there any way to translate it using trados, or do I need to translate each record within Access itself?

Any help will be appreciated.

Regards

[Editado a las 2008-01-14 17:36]


Direct link Reply with quote
 

Selcuk Akyuz  Identity Verified
Turkey
Local time: 15:12
Member (2006)
English to Turkish
+ ...
Possible solution Jan 14, 2008

I have looked at your profile page and I see that Deja Vu is listed among the software you use. Although I did not tested it, according to the user's manual of Deja Vu you can translate MS Access files with DV.

Direct link Reply with quote
 

Samuel Murray  Identity Verified
Netherlands
Local time: 13:12
Member (2006)
English to Afrikaans
+ ...
I'd love to try it in OmegaT... Jan 14, 2008

Edwal Rospigliosi wrote:
I have an Access (.mdb) file to translate. Is there any way to translate it using trados, or do I need to translate each record within Access itself?


If anyone wants to send me an Access file, I'd love to try it out in OmegaT.


Direct link Reply with quote
 
xxxmediamatrix
Local time: 09:12
Spanish to English
+ ...
Clarification, please... Jan 14, 2008

Edwal Rospigliosi wrote:
I have an Access (.mdb) file to translate. Is there any way to translate it using trados?


1) Do you mean your client wants you to translate all the data held in the Access file, or are you required only to translate the user interface (the forms and reports)?

2) Do you mean that you are expected to use a CAT tool for this job? If so, then sorry, but you are on your own (as far as I'm concerned....).

3) If you are required to translate the actual data, then the best approach will depend on the type of data - and how many records there are. For example, there's a world of difference between a 200-word bilingual glossary and, say, the New York yellow pages.

4) If you're expected to translate only the interface, then you need to work directly in Access. Make a copy of each form/report (with a new name, so the original forms/reports are preserved) and over-write the existing text (mostly label and caption controls) as appropriate. Note that if the forms/reports contain sub-forms/sub-reports then you will have to set up the parent/child relationships to suit the new (sub)form/(sub)report names, and also check that any queries using parameters drawn from the (sub)forms/(sub)reports still work correctly.

5) .... errr, no, that will do for starters, I guess!

MediaMatrix


Direct link Reply with quote
 

Edwal Rospigliosi  Identity Verified
Spain
Local time: 13:12
English to Spanish
+ ...
TOPIC STARTER
Clarification Jan 14, 2008

My case is 1), I have to translate both the data and the interface.

2) No, I'm not expected to use a CAT Tool, but to enter into each record, translate it and save it, specially when part of the data falls into the "fuzzy match" category, calls for a lot of extra work that might be avoided by using a CAT tool. I'll try DejaVu, hope it works.

3) The word count is in the vicinity of 60,000 words.

4) Thank you, I'll take it in account.

Thanks everybody by your help


Direct link Reply with quote
 
xxxmediamatrix
Local time: 09:12
Spanish to English
+ ...
Follow-up Jan 15, 2008

Even with this additional 'context' there are still many unknown factors that might play havoc with your translation - or, alternatively, make it a whole lot easier. For example:

a) If (as is usually the case) the data entry form is built 'on the fly' using a query that takes data from several tables, then you can save a lot of time (and typing) by translating some of those tables in 'Table' view. For example, if the database concerns people then one of the data fields is likely to be 'Sex' (oops! 'Gender'). Associated with this field there will either be a small table offering three ( ) options (male/female/unknown ) or those options will be hard-coded in a drop-down list ('List' property of a list or combo control, for example) in the form itself. Either way, if you translate the source data, in the table or in the drop-down list, you will avoid having to type 'male/female/unknown' again and again for every record.

b) Assuming that your final product will be a separate target-language 'clone' of the complete source database, then (with one proviso) you can work directly on a copy of the source database file. The proviso is that the source file should not be a member of a replication set (otherwise, next time the database user syncronises his/her data with other replicated copies, everyone's data may be corrupted.) If in doubt on this point, look for GUID fields in the tables (if they are present, it's been replicated) - or ask your client (assuming your client is likely to know...).

c) If you make a straight copy of the source database, then you can forget item 4) in my previous post, since the (sub)form/(sub)report names will not be changed. However, you may find it helpful to change the 'Language' property throughout the database so the spell-ckecker will work properly (at least, as well as MS thinks it should ).

d) If your translation is supposed to end up embedded within the original database (i.e. making the interface and the data bilingual), then unless you are a competent Access programmer I suggest you should decline this job. And if you do have the necessary skills, then you should charge your client not only for the translation but also for the Access development work (which will cost them more than the 60,000 word translation).

e) If you still want to use Trados on this (and I repeat, I'm not a CAT user myself, so...) then I guess one approach would be to export the Access tables to Word, translate Word in Trados and then import the result back into Access. And I imagine that's what CATs do with databases anyway... There are some more potential problems - two that come rapidly to mind are:
- if any of the tables include AutoNumber fields for record (or table row) identification then the numbers in the re-imported data will probably not tally with those in the source datafile, even if you delete the source language data before reimporting the translation. This will be a problem if someone wants to link the two databases later on the basis of those ID numbers (there's a way round the problem, but best left to a proframmer...);
- if anything (tables, list/combo boxes, etc.) is sorted alphabetically (including inadvertent sorting during the export/translation/import process), then there might be a hiatus between the language versions sufficient to prevent interworking of the two langage versions.

f) The lesson from all this is that if anyone needs a bi/multilingual database, it's far better to design it to be bi/multilingual from the very start of the development process. (And the same goes for web-site design...).

MediaMatrix


Direct link Reply with quote
 

Soonthon LUPKITARO(Ph.D.)  Identity Verified
Thailand
Local time: 19:12
Partial member (2004)
English to Thai
+ ...
Trados T-Window for Clipboard Jan 15, 2008

I am a fan of Trados T-Window for Clipboard if I meet with special application to use.
Its copy & paste and CAT functions are convenient to use. Please try it.

Regards,
Soonthon L.


Direct link Reply with quote
 

Samuel Murray  Identity Verified
Netherlands
Local time: 13:12
Member (2006)
English to Afrikaans
+ ...
Good point... Jan 15, 2008

mediamatrix wrote:
1) Do you mean your client wants you to translate all the data held in the Access file, or are you required only to translate the user interface (the forms and reports)?


Good point. If the OP needs to translate the interface, he can do it manually. If he needs to translate the content, well, why not export the data to a more sane format like a flat file (eg CSV), translate it and then import it again. You may need to export various tables individually, but it'll still save time because all the data in a single table is likely to be of the same kind and therefor more likely to contain fuzzies.

Make a copy of each form/report (with a new name, so the original forms/reports are preserved) and over-write the existing text (mostly label and caption controls) as appropriate.


It would have never occurred to me to make copies so that the original forms are preserved. Why should the OP do this? Why can't he just translate everything so that the end result is a new Access file with only the target text in it?


Direct link Reply with quote
 
xxxBrandis
Local time: 13:12
English to German
+ ...
a work around... Jan 15, 2008

Hi! there,

Initially export all the tables from access to a working folder, rig them in tag editor, clean and reimport them into access. The newly imported tables will then either be marked as (2), as in table - clients and table-clients (2) or a duplicate table. Remove the earlier source tables and rename the target files with the original names, removing the duplicate marking or the (2) part. Bingo your access mdb is complete. Brandis


Direct link Reply with quote
 
xxxmediamatrix
Local time: 09:12
Spanish to English
+ ...
Why make copies? Jan 15, 2008

Samuel Murray wrote:
It would have never occurred to me to make copies so that the original forms are preserved. Why should the OP do this? Why can't he just translate everything so that the end result is a new Access file with only the target text in it?


I'm sure we all make a back-up copy of any file we're working on, regardless of the file format, just in case something goes disastrously wrong while we're translating. And all the more so if we are over-writing the source text.

Well, in the the case of a database (Access or any other breed) the scope for things 'going wrong' is considerably greater than in a Word file, for example. So it makes sense not only to keep a back-up of the complete original database (even regardless of the proviso mentioned in b) of my previous post), but also to make clean copies within the database itself of its major interface components - the forms and reports - especially if you are going to over-write those components. It's quicker and easier to delete the form you inadvertently mis-handled, make a fresh copy from the internal back-up and start again than it is to start importing bits and pieces from your back-up of the complete file (although, true, that is also an option).

MediaMatrix


Direct link Reply with quote
 
xxxmediamatrix
Local time: 09:12
Spanish to English
+ ...
Access database download Jan 15, 2008

Samuel Murray wrote:

If anyone wants to send me an Access file, I'd love to try it out in OmegaT.


You can download the classic MS Access sample database, Nwind.mdb here: http://www.microsoft.com/downloads/details.aspx?familyid=C6661372-8DBE-422B-8676-C632D66C529C&displaylang=en (476 KB)

Of course, this sample database, being an MS product designed as an example of 'best practice' in Access development, is not necessarily typical, in terms of its 'inner workings' and/or complexity, of the mass of Access databases built by other developers, but it will at least serve to gain initial insight into the problems of database translation, whether manual or with a CAT.

If you try this with OmegaT (or any other tools) it would no doubt be interesting for all of us to know how you get on!

MediaMatrix


Direct link Reply with quote
 
xxxmediamatrix
Local time: 09:12
Spanish to English
+ ...
Bingo ... ? Jan 15, 2008

Brandis wrote:
Initially export all the tables from access to a working folder, rig them in tag editor, clean and reimport them into access. The newly imported tables will then either be marked as (2), as in table - clients and table-clients (2) or a duplicate table. Remove the earlier source tables and rename the target files with the original names, removing the duplicate marking or the (2) part. Bingo your access mdb is complete.


Unfortunately, the process is usually not that simple, Brandis.

In particular, when you re-import the tables Access will assign field types to the table columns on the basis of the kinds of data it finds (numbers, text, etc.). And for texts, it will asign field lengths based on the database defaults or the longest record it finds. These field types/lengths may not (almost certainly will not) match those of the original tables. More importantly, if a table has an autonumber field (for record ID purposes), those numbers (which are auto-incrementing long integers) will export as plain numbers and will then re-import as numbers of what ever kind is set up as the database default number representation, maybe long integers, maybe ... double precision or whatever. The autonumbering of the source tables will be lost.

At first sight, a work around to this problem would be to re-import the translated table into the original table (thus retaining the field types/lengths) but the imported autonumbers will all change (starting with the next number after the last number in the source table). And this will happen even if you delete the records from the source table before importing. As mentioned in a previous post, there is a work-around for this - but it requires Access and SQL programming skills. Of course in some databases the exact numbering may not matter - but if those numbers are a primary key, or are used to cross-reference to other tables, then they must not be changed.

MediaMatrix


Direct link Reply with quote
 
Renate Reinartz  Identity Verified
Germany
Local time: 13:12
English to German
Google for Access software localization Jan 15, 2008

Edwal Rospigliosi wrote:

Hi

I have an Access (.mdb) file to translate. Is there any way to translate it using trados, or do I need to translate each record within Access itself?

Any help will be appreciated.

Regards

[Editado a las 2008-01-14 17:36]


I don't want to do a shameless plug. But why you don't just google for

Access software localization



Renate


Direct link Reply with quote
 
xxxmediamatrix
Local time: 09:12
Spanish to English
+ ...
One reason? Jan 15, 2008

Renate Reinartz wrote:

I don't want to do a shameless plug. But why you don't just google for

Access software localization



Renate


Google replied:
Your search - "Access software localization" - did not match any documents.


MediaMatrix


Direct link Reply with quote
 

Antoní­n Otáhal
Local time: 13:12
Member (2005)
English to Czech
+ ...
Interface and data; web link Jan 15, 2008

(1) Translating interface:
IMHO, one should not (and need not) rename fields in tables at all - for example, I often use English names for fields in Czech databases (they are usually more succint, I avoid problems with accented letter if and when communcation between "local Access" and "online MySQL" databases takes place). Since users do not actually see the field names, it should be sufficient to rename labels in forms and reports - this can probably be automated to a certain extent if you are able to use VBA.

(2) Translating data:
The procedure export tables- translate in CSV text or Excel (or maybe other formats)- import the outcome of this translation step is easy in principle; one should be careful about compliance of the translated data with the original tables' design, though. To give a simple example that comes to my mind, if there was a dropdown in the source language with text options and the longest option was 5 characters long and the dabase was "optimised" so that 5 is chosen as the dimension of that field, if one of the translated options exceeds 5 in length, you have to "interfere" with the original design; etc.

(3) a simple Google search gave this link:

http://www.alchemysoftware.ie/tutorials/content/translatingmsaccessfiles.htm


HTH
Antonin


Direct link Reply with quote
 
Pages in topic:   [1 2] >


To report site rules violations or get help, contact a site moderator:


You can also contact site staff by submitting a support request »

How to translate an MS Access file?

Advanced search






CafeTran Espresso
You've never met a CAT tool this clever!

Translate faster & easier, using a sophisticated CAT tool built by a translator / developer. Accept jobs from clients who use SDL Trados, MemoQ, Wordfast & major CAT tools. Download and start using CafeTran Espresso -- for free

More info »
Wordfast Pro
Translation Memory Software for Any Platform

Exclusive discount for ProZ.com users! Save over 13% when purchasing Wordfast Pro through ProZ.com. Wordfast is the world's #1 provider of platform-independent Translation Memory software. Consistently ranked the most user-friendly and highest value

More info »



All of ProZ.com
  • All of ProZ.com
  • Term search
  • Jobs