How to translate an entire Access database? Thread poster: Ángel Belinchón
|
|---|
Hello,
I have a client who is asking me to translate a whole Access 2010 database.
He is planning to use it together with a reference book for this application.
Is there any way to do it using a CAT Tool?
Thanks in advance.
| | | | Jean Lachaud 
United States
Local time: 21:23
English to French
+ ...
| Export it to CSV | Mar 7, 2011 |
The db may or may not be exported to a TM-compatible format, such as a CSV file.
FWIW, Open Office database component can open Access files, so you may be able to play for free (in free, I mean "no cash spent") with the database and try a few options.
| | | | Theo Bernards (X)
France
Local time: 03:23
English to Dutch
+ ...
| It has been many years since I worked with Access, but... | Mar 7, 2011 |
I seem to remember that it is possible to export Access databases into spreadsheets. Would that be an option for your client or yourself or would the database be too large for that?
| | | | LEXpert
United States
Local time: 20:23
Member (2008)
Croatian to English
+ ...
| By tables, in Excel | Mar 7, 2011 |
Export the tables to Excel files. Translate with the CAT tool of your choice. Import back.
| | |
|
|
|
mediamatrix (X)
Local time: 21:23
Spanish to English
+ ...
| If in doubt, don’t. | Mar 7, 2011 |
The fact that you are asking this question here in the forum suggests that you are not familiar with the problems and risks associated with translating a database that has (perhaps) not been designed with multi-lingualism in mind from the outset.
A database (Access or any other) has several main layers which, simplifying enormously, can be labelled ‘data’, ‘number-crunching’, and ‘interface’.
If the client just wants the data translated, then Rudolf’s appr... See more The fact that you are asking this question here in the forum suggests that you are not familiar with the problems and risks associated with translating a database that has (perhaps) not been designed with multi-lingualism in mind from the outset.
A database (Access or any other) has several main layers which, simplifying enormously, can be labelled ‘data’, ‘number-crunching’, and ‘interface’.
If the client just wants the data translated, then Rudolf’s approach may give satisfactory results if the database is properly normalised (if it’s not, then watch out for false matches).
But if the client wants you to translate the ‘entire’ database, interface included, then it’s significantly more complicated, to an extent that depends on how it has been built in the source language.
Suggestion: If in doubt, don’t.
MediaMatrix ▲ Collapse
| | | | Ángel Belinchón
Spain
Local time: 03:23
English to Spanish
+ ...
TOPIC STARTER | Too difficult... | Mar 8, 2011 |
Thank you all for your comments.
Indeed, this database is too large. It includes not only tables, but reports, macros, forms, etc., so I guess Excel export won't be enough.
| | | | | There are several options | Mar 8, 2011 |
Hello
As mediamatrix said there there are several, different ways to translate a database. That is, you have to know more about what your client wants.
If you want, we can take a look at the database (for free) and see what technical options you have in translating the it. We have experience in enabling localization of Access databases so I expect it would be very straightforward. But the main thing is that your client tells you exactly what they want.
... See more Hello
As mediamatrix said there there are several, different ways to translate a database. That is, you have to know more about what your client wants.
If you want, we can take a look at the database (for free) and see what technical options you have in translating the it. We have experience in enabling localization of Access databases so I expect it would be very straightforward. But the main thing is that your client tells you exactly what they want.
BTW I would not recommend Excel for the job. Sometimes it works ok but you might encounter severe problems e.g. if you have different characters set in your computer (compared to your client).
Best regards
Niko
--
MULTILIZER
Managing Director ▲ Collapse
| | | | Steven Capsuto
United States
Local time: 21:23
Member (2004)
Spanish to English
+ ...
TraduccionesABC wrote:
Thank you all for your comments.
Indeed, this database is too large. It includes not only tables, but reports, macros, forms, etc., so I guess Excel export won't be enough.
Basically, the job requires someone who is both a translator and an Access developer.
There are all sorts of potential pitfalls. For instance, there can be calculated fields in a report that display different text depending on data in the database. For instance, if profession = professor, a hidden field and label might automatically become visible to indicate where the person teaches. If the word "professor" has been changed to a word in another language, the equation won't work anymore. So you'd have to go into the equation for each calculated field and each conditional statement in every report and every screen and localize the whole thing. It takes hours and hours of work, it's a pain in the neck, and it's really easy to make a simple mistake and "break" the database.
I was an Access developer for about ten years and even I generally don't take these types of localization jobs. Give me a simple Word document or PDF any day.
| | |
|
|
|
| Database developers skill may not be required | Mar 10, 2011 |
I just read Steven's posting. I partly agree with him but not completely.
Typically database is just a storage of data. However, Microsoft Access is not only storage of data but it may be used also as a software development tool. That is, there are two sides in MS Access, "normal" database and software development tool.
When the localization projects includes localization of also software written with MS Access, I completely agree with Steven. Then you essentially have ... See more I just read Steven's posting. I partly agree with him but not completely.
Typically database is just a storage of data. However, Microsoft Access is not only storage of data but it may be used also as a software development tool. That is, there are two sides in MS Access, "normal" database and software development tool.
When the localization projects includes localization of also software written with MS Access, I completely agree with Steven. Then you essentially have a software localization project.
But it might also be so that only database data should be localized (and not the software developed with Access). In this case the project is must simpler, it might even be very simple.
TraduccionesABC mentioned that the project includes also forms, macros, etc. This implies that it is probably essentially a software localization project. And in this case Steven's comments are very relevant. ▲ Collapse
| | | | 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 entire Access database? | TM-Town | Manage your TMs and Terms ... and boost your translation business
Are you ready for something fresh in the industry? TM-Town is a unique new site for you -- the freelance translator -- to store, manage and share translation memories (TMs) and glossaries...and potentially meet new clients on the basis of your prior work.
More info » |
| | Trados Business Manager Lite | Create customer quotes and invoices from within Trados Studio
Trados Business Manager Lite helps to simplify and speed up some of the daily tasks, such as invoicing and reporting, associated with running your freelance translation business.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
Translation news
