Translation Errors 3

Funny translation errors from One Stop Shop Translations, third in the series
http://www.onestopshoptranslations.com/

Translation Errors

Second in the series of translation errors from around the world

Documentation Localization: Background and Methodology

Welcome to the latest in the series of “Localization: The Definitive Guide”, a complete step by step guide to the localization of websites, software and it’s components. In this article we will deal with the translation of documentation associated with software. We have already dealt with the localization of software and Online Help. Again, the localization of software documentation ties in with the localization of the software or User Interface and the Online Help. The documentation of software may include User Guides, Quick User Guides, CD-ROM covers and Box text and any other marketing material. Just to refresh a SIM ship release is where the language versions of the product are released to their respective markets on the same date as the original version. As one can imagine cross referencing with other localization components is crucial ensuring that all components are consistent with each other. It’s also important to bear in mind how astronomical the cost of localization can become now, bearing in mind the amount of languages we need to deliver and the volume of words we have to translate. In many cases, companies often combat these astronomical localization costs by tying the Online Help in with the User Guides and Quick start Guides by having just one guide for all three and in some cases not even printing the User Guides. As already discussed we translate the user interface first, populate the translation memory and Glossary with the translated text and then run it against the Online Help and User manuals. However with a SIM ship version and the time constraint we need to translate the OLH and User manuals in parallel with the User Interface. The process for the translation of the documentation is very similar to the translation of a website, OLH or the User interface itself so, as mentioned previously in the OLH localization article please bear in mind that there will be some overlap between this article and the others in this series. We have already discussed the use of translation memories, resources and infrastructure and their respective influences on the localization work flow but in this article we will focus more on the formats of User Guides and an extra resource called Desktop publishing. In most cases the overlap between the Online Help and the User Guides is substantial if not the same however, the extra dimension of publishing introduced into the localization work flow causes costly and substantial changes.

1. Pseudo Localization of Manuals

As opposed to the UI and OLH the User manuals are not pseudo translated.

2. Pilot Language for Online Help Localization

We immediately begin the documentation localization process based on the language/s already chosen for the OLH and user interface. This language will define the localization process and weed out the majority of the localization bugs.

3. Translation Memory and Glossary input during Online Help localization.

The documentation localization process is similar to the Online Help and UI translation process in that the translatable text is isolated, translated and dumped back into the original format, however, there is an extra degree of complexity if there are translation Memories involved in the process and an even greater degree of complexity if the translation memory is not centralized. Please refer to translation memory input during OLH localization for more information. Also, all the engineering localization tasks for the OLH and UI involved localization engineers. For these tasks during the localization of the documentation we call on a different resource called a desk top publisher. The desk top publisher tasks include preparing the original files for translation within a compatible format for the TM environment, bug fixing and formatting, rebuilding/compiling the translated manuals, functional testing and updating the translation memories with functional and linguistic fixes. In the previous article on the localization of Online Help we took into account two types of translation memory models, Centralized and non-centralized translation memory work flows. It is here that the localization process of the manuals can vary greatly depending on the translation memory, the infrastructure and resources chosen by the translation services company.

The main formats of User Guide files are quark and frameMaker and a lot of translation memory environments can work directly with these formats.

4. Translation and Revision of Documentation

Ok, so we send the translator the translation memory compatible files to translate or access to the centralized translation memory system portal , the most up to date Translation Memory (as they need to update it with their work) reference material such as Glossaries, previous User Guides…etc.. and the translator begins translation. As discussed in the previous paragraph one must bear in mind that the process can vary in many ways when we take into consideration that the translator may be in-house or external or the translation memory system we are using. What is key is that each resource always has a reasonably up to date TM to work with to avoid duplication of work. During this stage the translator’s job remit may overlap with the publishers in that he/she may be responsible for typical localization bugs such as resizing of strings as he translates or it may be the publisher’s job after translation. The end product is an 80 to 90% localized pilot version. What adds even more to the complications of the project is whether the documentation is revised by the translation company, the client or a third party. What if the client wants to revise the User Guides? What if the client does not wish to use the translation memory process

5. Translated User Guides

During the next stage the pilot version is rebuilt for testing.

6. Localization QA - Testing of localized Documentation

Localization testing of Documentation is the same as for the software in that once recompiled the pilot version is tested for functional bugs by the Localization QA team and linguistically tested, with the UI in context, by the translators or in some cases by third party linguists. The bugs are usually documented via post-its on the pdf and sent to desktop Publishing in the case of functional and formatting bugs , or translation, in the case of linguistic bugs, to be fixed. This cycle continues until the translated software is bug free. The set-up of the phase can differ from company to company depending on the circumstances but in all cases it’s important to update the TMs with the linguistic fixes. There is an extra degree of complexity during this phase compared to the software localization QA in that the cross referencing and linking to the software is fully functional

7.

Translation of other Language Versions of Manuals

Now that we have our pilot version localized and bug free, the process is in place to translate the other language versions of the User Guides. I mentioned at the start of this article that in an ideal world the localized versions should be released on the same date as the master version however it’s usually impossible to achieve this and what usually happens is that certain languages are given priority depending on their market importance. The more important languages are called tier one languages and the less important languages for secondary markets are generally referred to as Tier 2 languages.
To summarize, I think this article gives us an idea of how close the software localization process, the Online Help localization process and the documentation process are intertwined in that every UI reference must be exactly the same in the Online Help and the user Guides and marketing materials. This article is part of a series, "Localization: The definitive Guide" from One Stop Shop Translations, which deals with the localization of each component of software, the others include:

- Software Localization: Background and Methodology
- Online Help Localization: Background and Methodology
- End User License Agreements Localization: Background and Methodology
- Software Documentation Localization(Quick User Guides and User Guides): Background and Methodology
- Website Localization: Background and Methodology

NOTE: Please note that translation and localization are used interchangeably in this article.
NOTE: Please note that documentation and User Guides are used interchangeably in this article.
DEF: Translation is the communication of the meaning of a source-language text by means of an equivalent target-language text.
DEF: Language localization is the process of adapting a product that has been previously translated into different languages to a specific country or region. Source: Wikipedia

If you like this post please "like" or "share" for more content

Mark Kieran, CEO, One Stop Shop Translations

For our latest User manual translation rates click on this link or get an economically unbeatable User Manual localization quote here.

Remember that translation of software is not just simple straight forward translation but a complicated process that involves many stages and specialized expertise!

Translation Mistakes

A production from One Stop Shop translations, Spain, displaying some horrendous translation mistakes in the commercial world that cost some companies a lot of money and embarrassment!

Online Help Localization: Background and Methodology

Welcome to the latest in the series of “Localization: The Definitive Guide”, a complete step by step guide to the localization of websites, software and it’s components. In this article we will deal with the translation of Online Help for software. Again this component ties in with the localization of the software or the User Interface (UI) and the race to release a SIM ship version of the localized product. Just to refresh a SIM ship release is where the language versions of the product are released to their respective markets on the same date as the original version. As one can imagine the cross referencing between the Online Help and the User Interface is very important. It is important to ensure that both are consistent with each other. In an ideal world we translate the user interface first, populate the translation memory and Glossary with the translated text and then run it against the Online Help. However with a SIM ship version and the time constraint we need to translate the OLH in parallel with the User Interface. The process for the translation of the OLH is very similar to the translation of a website or the User interface itself, in fact some Help systems are web based so please bear in mind that there will be some overlap between this article and the others in this series. For this article we will take the worst case scenario of a SIM ship release where both the software and the Online Help are translated at the same time. One thing in our favor is that the User interface word count is usually substantially lower than the online help word count which gives us time to ensure during revision that the references and links from the Online Help to the software reference correctly.

1. Pseudo Localization of Online Help

As with the software, one of the first steps is to pseudo-translate the online help pilot language/s. Just to refresh our memories, the pilot languages are a small cross section of languages to represent all the target languages to be translated. Please refer to pseudo translation of software here to refresh your memory on its purpose and benefits.

2. Pilot Language for Online Help Localization

Now we begin the Online Help localization process in earnest by starting its localization based on the pilot language/s already chosen for the software. This language will define the localization process and weed out the majority of the localization bugs.

3. Translation Memory and Glossary input during Online Help localization.

The online Help localization process is similar to the pseudo translation process in that the translatable text is isolated, translated and dumped back into the Online Help, however, there is an extra degree of complexity if there are translation Memories involved in the process and an even greater degree of complexity if the translation memory is not centralized. Please refer to translation memory input during software localization for additional information. Lets take a step forward and assume that our Help system has been pseudo translated, bug fixed and prepared for the TM environment. It is here that the localization process of the online Help can vary greatly depending on the translation memory, the infrastructure and the resources chosen by the translation services company. Lets take a couple of scenarios I hope will cover the majority of localization process cases.

Centralized Translation memory Model

A centralized translation Memory is a central repository of previously translated segments and Glossary terminology. The system is interactive and allows the translator to access a “live” translation memory and glossary. It means that all translation resources both internal and external work from the same TM and the translated text is updated on the “fly”. It ensures that all translators are up to date with the most current terminology and translations. Centralized translation memories are often complex and expensive to implement resulting in higher costs but worth it in the long run by cutting time, long term costs and enhancing quality and consistency.

Let’s take a quick run through the centralized translation memory process. Let’s assume we have started the user interface and online Help translation in unison. This may result in different translations for User Interface commands and options in both components. In this case the reviewer of the User interface will have final sign-off on all the UI text. If there are any issues he will discuss this with the translator of the User Interface and translator and reviewer of the online Help to reach a general consensus on the best translation and be responsible for updating the central TM. The translator and reviewer of the OLH will receive notifications of TM updates and can update their target texts accordingly on the fly. In a lot of cases if a translator is external they will need access to the centralized translation memory system by means of a portal.

Translation Memory Model (Not centralized)

The second model is more cumbersome and complicates the process as the translation memory is not centralized. It means that the translator cannot update his text while he is working. It complicates the parallel translation in that at the end of the day for instance, both translation memories differ i.e. the UI reviewer TM and the OLH reviewer TM, or may even involve syncing many more TMs for instance, UI reviewer TM, the OLH reviewer TM, UI translator TM and OLH translator TM, depending on the amount of resources working concurrently on the same text. There are workarounds but they involve extra management and process bottlenecks. For instance we could devise a process where at the end of the day a central resource takes the UI translators TM and updates it with his changes. The most up to date TM is then sent to the OLH translator and UI translator at the beginning of each day to begin their work. As one can imagine its not an ideal situation! For a demonstration on a Translation memory environment please refer to the following link.

4. Translation and Revision of the Online Help

Ok, so we send the translator the translation memory compatible files to translate or access to the centralized translation memory system portal , the most up to date Translation Memory (as they need to update it with their work) reference material such as Glossaries, previous User Guides…etc.. and the translator begins translation. As discussed in the previous paragraph one must bear in mind that the process can vary in many ways when we take into consideration that the translator may be in-house or external or the translation memory system we are using. What is key is that each resource always has a reasonably up to date TM to work with to avoid duplication of work. We also discussed in the localization of software that the translator may be responsible for typical localization bugs such as resizing of dialogues and menus and duplicate hot keys or this may be the role of the localization engineers after translation. The end product is an 80 to 90% localized pilot version. What adds even more to the complications of the project is whether the Online help is revised by the translation company, the client or a third party. What if the client wants to revise the OLH? What if the client does not wish to use the translation memory process instigated by the translation company?

5. Translated Online Help Build

During the next stage the pilot version is rebuilt for testing on various platforms.

6. Localization QA - Testing of localized Online Help

Localization testing of Online Help is the same as for the software in that once rebuilt the pilot version is tested for functional bugs by the Localization QA team and linguistically tested, with the UI in context, by the translators or in some cases by third party linguists. The bugs are documented and sent to engineering in the case of functional bugs, or translation, in the case of linguistic bugs, to be fixed. This cycle continues until the translated software is bug free. The set-up of the phase can differ from company to company depending on the circumstances but in all cases it’s important to update the TMs with the linguistic fixes. There is an extra degree of complexity during this phase compared to the software localization QA in that the cross referencing and linking to the software is fully functional and corresponds linguistically

7. Translation of other Online Help language versions

Now that we have our pilot version localized and bug free, the process is in place to translate the other Online Help language versions. I mentioned at the start of this article that in an ideal world the localized versions should be released on the same date as the master version however it’s usually impossible to achieve this and what usually happens is that certain languages are given priority depending on their market importance. The more important languages are called tier one languages and the less important languages for secondary markets are generally referred to as Tier 2 languages.
To summarize, I think this article gives us an idea of how closely the software localization process and the Online Help localization process are intertwined in that, every UI reference must be exactly the same in the Online Help. This article is part of a series, "Localization: The definitive Guide" from One Stop Shop Translations, which deals with the localization of each component of software, the others include:

- Software Localization: Background and Methodology
- End User License Agreements Localization: Background and Methodology
- Software Documentation Localization(Quick User Guides and User Guides): Background and Methodology
- Website Localization: Background and Methodology

NOTE: Please note that translation and localization are used interchangeably in this article.
DEF: Translation is the communication of the meaning of a source-language text by means of an equivalent target-language text.
DEF: Language localization is the process of adapting a product that has been previously translated into different languages to a specific country or region. Source: Wikipedia

If you like this post please "like" or "share" for more content

Mark Kieran, CEO, One Stop Shop Translations

For our latest online Help localization rates click on this link or get an economically unbeatable Online Help localization quote here.

Remember that translation of software is not just simple straight forward translation but a complicated process that involves many stages and specialized expertise!

Localization: The Definitive Guide

During the month of October One Stop Shop translations is releasing "Localization: The definitive guide". A user guide for students and localization professionals, the guide contains a series of articles with each one dealing in detail with the localization process for each component of software. The articles are written from a component point of view as opposed to a process point of view in that it details the process of each component individually. Please note that this is may lead to some overlapping between the articles. The links to each article are as follows:

- Software Localization: Background and Methodology
- Online Help Localization: Background and Methodology
- End User License Agreements Localization: Background and Methodology
- Software Documentation Localization(Quick User Guides and User Guides): Background and Methodology
- Website Localization: Background and Methodology

Please note that the best order to read this series is as follows, Software, Online Help, Documentation, End User Licence and Websites!

If you like this post please "like" or "share" for more content

Mark Kieran, CEO, One Stop Shop Translations

For more information on our localization services click on this link or get an economically unbeatable software localization quote here.

Remember that translation of software is not just simple straight forward translation but a complicated process that involves many stages and specialized expertise called software localization!

Software Localization: Background and Methodology

One of the major headaches for software development companies is Software Localization and the release of a SIM ship version of their software to market. In an ideal world the localized or translated versions of the software should be released to market on the same date as the original version which is usually English, a concept known as SIM ship software. With this in mind it is important to run the localization process in parallel with the initial development process. If we delay the localization cycle until the end of the development process this will incur extra costs and also delay the SIM ship version of the software due source code changes caused by the localization process. To overcome these difficulties there are a number of preemptive localization steps that we can take in parallel with software development.

1. Pseudo Localization of Software

Our first step is to pseudo-translate the software pilot languages. If we have many languages to localize (translate) we choose a small cross section of languages to represent all the target languages to be translated. During pseudo localization the target text is pseudo translated as follows:
- The translatable text is isolated
- The translatable text is pseudo translated
- The pseudo translated text it is dumped back into the software code
The pseudo translated text represents the target language and can uncover various functionality and UI bugs during initial development that can be fixed at this stage as opposed to during the software localization/translation phase when it may be too difficult or expensive to fix! Some of the typical bugs uncovered during the pseudo translation phase include:
- Rendering of the target text on the UI. The target text is more often than not longer than the source text especially in the case of English making the text appear cut or overlap other UI components. For instance in the case of English, the other main European FIGS (French, Italian, German and Spanish) languages can be up to 30% longer than English. This allows us to set character limits for menus and dialogues before translation begins.
- Glyphs such as the accent or acute not found in the source language may be cut off in the target language. - Languages such as Arabic that read right to left may cause serious input issues
- The original character set may not accommodate all the source characters
- Identifying hard coded text where the localizable text is embedded in the code
Catching these bugs during pseudo translation of the software ensures a seamless translation phase! The pseudo translation generally identifies all the most common problems of the target versions. Its best to run the pseudo translation when the original version is fully functional.

2. Pilot Language for Software Localization

Now we begin the software localization process in earnest by choosing a pilot language which is a language version of the software translated before the other languages. This language will define the localization process and weed out the majority of the localization bugs.

3. Translation Memory Input during software localization.

The actual software localization process is similar to the pseudo translation process in that the translatable text is isolated, translated and dumped back into the software, however, there is an extra degree of complexity if there are translation Memories involved in the process, as follows. A translation memory is in essence a memory bank of previously translated target text. It is also an environment in which the translator works and has other advantages such as Glossaries to enhance quality and consistency and speed up the translation process. However, once the source text has been isolated we need to ensure that its format is compatible with the TM environment and that all translators are capable of working within the TM environment. Once this has been established we recuperate the previously translated text with the end result being that the translator receives a Translation Memory compatible file with all the previously translated text integrated. This is especially the case for software updates where large sections of the software remain the same which has an obvious saving on costs and time and ensures consistency and quality. The most obvious software translator environment of this type is alchemy catalyst. For a demonstration on a Translation memory environment please refer to the following link.

4. Translation and Revision of the software

Ok, so we send the translator the translation memory compatible files to translate, the most up to date Translation Memory (as they need to update it with their work) reference material such as Glossaries, previous User Guides…etc.. and the translator begins translation. During this stage one must bear in mind that the process can vary in many ways when we take into consideration that the translator may be in-house or external. Also, the translator may be responsible for typical localization bugs such as resizing of dialogues and menus and duplicate hot keys or this may be the role of the localization engineers after translation. The end product is an 80 to 90% localized pilot version. It is then revised by the translation company, the client or a third party depending on the software localization process defined at the start of the project?

5. Translated Software Build

During the next stage the pilot version is rebuilt for testing on various platforms.

6. Localization QA - Testing of localized software

Once rebuilt the pilot version is tested for functional bugs by the Localization QA team and linguistically tested, with the UI in context, by the translators or in some cases by third party linguists. The bugs are documented and sent to engineering in the case of functional bugs, or translation, in the case of linguistic bugs, to be fixed. This cycle continues until the translated software is bug free. The set-up of the phase can differ from company to company depending on the circumstances but in all cases it’s important to update the TMs with the linguistic fixes.

7.

Translation of other software language versions

Now that we have our pilot version localized and bug free, the process is in place to translate the other software language versions. I mentioned at the start of this article that in an ideal world the localized versions should be released on the same date as the master version however it’s usually impossible to achieve this and what usually happens is that certain languages are given priority depending on their market importance. The more important languages are called tier one languages and the less important languages for secondary markets are generally referred to as Tier 2 languages.
So there you have it in a nutshell, the software localization process but we must also bear in mind the additional components of the software such as the Online Help and documentation need to be localized in parallel with the software. Below are additional links for an insight into how these additional components are localized, the articles below belong to the series, "Localization: The definitive Guide" from One Stop Shop Translations:

- Online Help Localization: Background and Methodology
- End User License Agreements Localization: Background and Methodology
- Software Documentation Localization(Quick User Guides and User Guides): Background and Methodology
- Website Localization: Background and Methodology

NOTE: Please note that translation and localization are used interchangeably in this article.
DEF: Translation is the communication of the meaning of a source-language text by means of an equivalent target-language text.
DEF: Language localization is the process of adapting a product that has been previously translated into different languages to a specific country or region. Source: Wikipedia

If you like this post please "like" or "share" for more content

Mark Kieran, CEO, One Stop Shop Translations

For our latest software localization rates click on this link or get an economically unbeatable software localization quote here.

Remember that translation of software is not just simple straight forward translation but a complicated process that involves many stages and specialized expertise!

Time management for Freelance translators

Those unfamiliar to the freelance translation profession usually think that freelance translators have more freedom with regard to their working hours and that they can work when and if they want! People seem to be under the impression that working from home without a boss is a wonderful existence!

Time and Time Management are key for the Freelance translator

Now let’s suppose that the freelance translator’s career is well on track with an established client base. Time management now becomes the key to the working life of the freelancer. If time is not managed correctly the life of the freelancer can become a living hell.

Working as a freelancer does not mean disrespecting normal working hours. On the contrary it requires a lot more discipline to organize the working day. If not, it could mean a disorganized working schedule with no personal life.

It often happens that freelancers at the start of their careers, place too much importance on the amount of work they need to do which of course is justified. OK, they have chosen this profession to do what they love, don’t have to go to the office, depend on others, work in other places etc. but there have to be boundaries, limits and rules to this working freedom by establishing concrete working hours that need to be adhered to rigidly. The following are a number of time management tips:

What are the working peaks and troughs of a freelance translator's day?

Often the freelance translator works better a certain times of the day. For instance in the mornings between 9 and 12 the translator may work more efficiently so we refer to this period as a peak work time. After lunch, for instance between 2 and 4 we find ourselves more lethargic and lacking energy. How do we organize our working time around these physical peak and trough working times? There are a number of workarounds but a suggestion is to do the more mentally taxing tasks such as translation at peak working times and then other less mentally taxing tasks such as administration and emails between 2pm and 4pm! Its only a suggestion and everyone works differently but its important to find your own rhythm for more efficiency!

How many times should the freelance translator check email?

Its important for the freelance translator to revise emails frequently especially if not doing so runs the risk of missing an important deadline or urgent text to translate, but a tough human habit to avoid is reading mails every time that the email dialogue pops up. Throughout the day this can be very time consuming and much better managed time wise if we revise the emails we receive periodically, say for instance, every two hours in one swoop, so to say. This avoids breaks in concentration and allows the translator to get into "email mode" which in essence is a different thought process than say, translation. I say two hours as a general rule of thumb and I think it’s an acceptable period within which to get back to a client. Alternatively, if the old habit is too hard to break why not program your inbox to “Send/Receive” every two hours.

Freelance translators working with different zones?

Given the nature of freelance Translation work many clients or Translation services companies are located in different time zones throughout the world: it’s important to establish this with the client at the onset of a working relationship. It can work to our advantage but in other cases for instance a Spanish Translator working for an Asian client, the freelancer has to be very clear at the start of the Project about the deadline and take the time difference loss into consideration when establishing it. Another suggestion is for the freelancer to program the email messenger to auto respond to the client or perspective client with the working hours and when to expect a response. This makes the client aware that there is a time zone issue

Freelance Translators should try Not to Work at Weekends?

I understand that this is easier said than done as most freelance translator deadlines tend to be yesterday and are always urgent but detaching from work is imperative to refresh the mind and body leaving us motivated and rearing to go on Monday morning. Granted, there are times where we haven’t planned correctly or a deadline’s urgency is unavoidable and we have to work on a Sunday. However, if this is the case it’s important to re-balance the work play barometer and take some time off on the Monday morning.

Its important to budget our time correctly and dedicate the appropriate amount of time to the multiple facets of Translation freelancer life for instance, Translation, administration, attending seminars, marketing, learning the latest tools etc…... What may help is keeping a task diary. Simply sit down on the Sunday evening and map out the task Schedule for the week while also taking into consideration peak and trough working times. Ensure that the task schedule is not over-ambitious and realistic, leaving enough time for a healthy personal life.

Workloads may also influence the task Schedule for instance, there may be extremely busy periods and tight deadlines for the freelance translator when there is no time for self-learning or attending seminars. Its important to take advantage of the less busy working periods and of course, managing them efficiently will lead to a greater sense of fulfillment, more opportunities and better professional development. During these periods we can revise Glossaries, do more marketing or study for exams. It’s important not to switch off during the less busy periods and keep the impetus and good working habits we have now established going. Apart from the bread and butter translation and administration work we have, we need to set professional objectives and gear our weekly tasks to achieving the objectives!

Managing Freelance translator Administration and Time

When working as a freelance translator, organization of administration tasks is very important. One has to establish an operative protocol that defines the delivery dates, invoicing, filing, procedures, query files, software maintenance, etc.

In general a rule of thumb is to send Translation invoices at the end of each month, in a way you can group small as well as large projects together and avoid minimal fees that tend to jeopardize the client relationship. But this is not the case very often as it may depend on each client and their requirements: some require invoices at the end of each Project, others at the end of the month, others when a certain sum of money is reached and so and so. If you are just starting out try using our Translation invoice template here. Simply fill in your details and you should be covered from all angles. It covers the client side contact details and fiscal details, your details such as address, fiscal details and bank account details and the project details such as the invoice date and due date, Word counts, Language combinations, taxes…etc… If you are dealing with an international transfer be sure to include your IBAN number and Swift code!

Given that invoicing is so important it’s important to simplify the process as much as possible. What we often recommend is that you request a Purchase order from the client. This is a great record of the project details agreed between the freelancer and client before translation commenced such as the rate agreed, the Language combination, delivery date, translation memory word counts and translation rates etc… If the project budget deviates significantly from the PO during the project its good to inform the client and request an updated PO which ensures that both are in total agreement with the extra works and the client will not get a nasty shock when they receive the final bill.

Some times administration can be boring as it is not a creative process but it is necessary. One has to invest the time in developing the efficiency of the administration processes to save time and also instill more confidence in the client!

I hope that this advice has been useful and saves you at least, some time that allows you a more active personal life. Of course any comments are welcome!

If you like this post please "like" or "share" for more content

Mark Kieran, CEO, One Stop Shop Translations

One Stop Shop Translations is a translation services company based in Madrid, Spain that hires translators on a freelance basis. We offer economically unbeatable translation quotes in most common language combinations of the world and fields of industry.

Try One Stop Shop Translations for Quality, price and timeliness!

One Stop Shop offering a 10% discount off 2013 translation rates

One Stop Shop Translations is offering a 10% discount off its 2013 translation prices with the following coupon, TRAONESTOPSHOP2013. Simply send your coupon number coupon number with your translation request and the discount will be taken in account accordingly in your quotation. This discount comes after a succession of translation rate cuts in 2012 due to the current economic climate but in no way reduce the quality of the translation services produced by One Stop Shop.

One Stop Shop Translation’s CEO, Mark Kieran says, “With this discount and the previous cuts in 2012 we see ourselves as one of the most competitive translation companies in the world considering the quality of the services we offer. We can still remain competitive due to our unique management model and translator loyalty we have built up over the years. ”

A translation quote can be requested can be requested on this link. Simply upload the files that need to be translated with any additional comments, for example, language combinations required and/or additional services required for example software localization or Desk Top Publishing. Add your coupon number to the translation quote request and then simply click the send button. You will receive a personalized quote the same day from a sales representative with your 10% discount added accordingly. Alternatively do an online translation quote here for an idea of the price you will pay. Simply enter the field of specialization of the document, the language combination and the word count and the price without VAT or the discount will be calculated directly on the screen. Please note for multiple languages and documents or more complicated requests you can send a request directly to sales@onestopshoptranslations.com or call our sales line on directly on 0034 91 365 9608.