Web site localisation involves cloning or pseudo-cloning after translation. Cloning means re-building the Web site using the software originally used to design the site, so that the target version has exactly the same functional and structural features as the original version (i.e. the same components and internal hierarchy). Pseudo- cloning entails either designing new components (which were not included in the original but are essential to ensure that all the main functional features work in the target user environment) or redesigning certain components, using different software from the one used originally and recreating a number of functional features required in the local environment, or restructuring the components to make the site more user-friendly for the target environment. The actual number of operators required will depend, as above, on the techniques used and the software available, on the technical nature of the product, and on the skills on hand for the job. The team will usually include at least one IT specialist. The job usually involves the following stages:
The shaded parts identify what the 'translators' would do as a matter of course. In fact, it is not uncommon for 'translators' to carry out the entire process single- handed.
1. The localisation environment is set up.
2. Site contents and architecture are retrieved.
3. The site functions and operation are analysed: the Web site's structure is broken down into sections and analysed. The site is tested for any malfunctions and errors (broken links, missing graphics, lack of uniformity, wrong addresses, inappropriate formats, etc.)
4. The localisation project is defined.
5. The adaptations required for the target market are identified, work specifications and the overall work schedule are drawn up.
6. The site is broken down into components.
7. The future site architecture is chosen.
8. All the different items are made ready for translation. This may involve tagging, conversions, setting up the translatable material within the appropriate hardware and software environment, etc. Further, the translator sets up the resources requires: platform, hardware, software, operators and other resources.
9. The international files are created. They include whatever does not require localisation (international images, plus anything that is fit for all languages).
10. The "images" directories are created.
11. Addresses are updated and upgraded.
12. The site is duplicated (or cloned). Folders and files are set up for each new language and the source files are transferred under their new (local) names.
13. All the links enabling circulation between the various language versions are created. Links are readdressed into the HTML or JavaScript or other files.
14. (as need be) same-type components are assembled into homogeneous sets of:
- text or code,
- scripts,
- frames,
- bars,
- 'pop-ups', which appear only in the source for the pages (as tool tips and legends),
- titles,
- sound files,
- images,
- user interfaces,
- other types (runtimes, databases, etc.)
15. The various components are made ready for translation (tagging, conversions, formatting, setting up into localisation environment, etc.)
16. The terminological and phraseological raw material is collected. Subject or topic studies are carried out as required.
The site contents are translated-localised. This means translation of:
- Text components (pages, pop ups, titles, interface messages, database tables, etc.
- Software components (downloadable files, access procedures, runtimes),
- Audiovisual components database, downloadable files, access procedures, runtimes, scripts, other linked Web sites, videos, etc.).
All the components required for the target site but not already in the original then have to be created and tested.
18. The non text items (graphics - animated and still images) are adapted and reprocessed.
19. The translation is proofread and checked.
20. Functional quality tests are carried out.
21. In the case of "pseudo-cloning": the site structure is created; the architecture is designed and built.
22. The translated (i.e. "localised") elements are reintegrated into the site structure. This entails:
- integrating translated code or text,
- integrating the frame files,
- integrating the titles,
- changing the necessary links within the translated files,
- checking the image source files in the translated files,
- re-integrating the legends,
- re-integrating the pop-ups,
- creating new links when required,
17. |
- adapting colours and user-interface if required.
23. All elements that were not present in the original but are deemed necessary for the target users are integrated and functional quality tested.
24. Offline Quality Control (functional tests are carried out on all user functions, links, short-cuts and mnemonic items, cross-checks between titles and table of contents, measurement checks). Functional tests must be carried out on as wide a variety as possible of formats and screen and navigator configurations.
25. Corrections, modifications, adaptations are made, followed by confirmation of the changes.
26. A Web-ready version is created.
27. Cultural acceptability and efficiency is tested. All necessary adaptations are made as the case may be.
28. Online Quality Control and validation are carried out.
29. (As the case may be) the main keywords that will make sure the site will be referenced by the main search engines are identified and the site is referenced.
2.4.1.3 Videogame localisation
The following is a description of the overall cycle of videogame design and localisation.
The shaded parts identify what the 'translators' do as a matter of course. The localisation project manager may be a translator.
a) Game design
Game design all starts with a game concept and a possible scenario the design team will turn into a playable demo so as to have a faint idea of what the actual game will look like. Publishers will make a market survey and draw up an investment plan. If the idea is validated, the game is developed by a team including:
- a scriptwriter, in charge of the story, the user manual and the scripts
- developers who will design and develop the software
- a graphics studio, to do the planning, modelling, texturing and lighting and to create the effects as well as the characters and the game's 'world' and to take care of the animation.
- A sound-recording studio, to record the voices and lyrics and music.
The quality of the text, the game and the soundtrack is thoroughly tested to the point of getting a perfect 'gold' version. The graphics experts create the layout of the front and back of the box as well as the CDROM and user manual covers. The advertising and marketing campaign is launched.
b) Translation-localisation into various languages
Localisation used to start once the game actually existed in the design language - usually English as a way of broadening the commercial prospects. Today, localisation tends to be carried out in parallel with the development of the ingames, scripts, and packagings in the design language, each component or element being sent for localisation as soon as it is ready and no longer according to a preset schedule. Frequent updates are necessary since the original version undergoes various changes in the course of development and all changes then have to be applied across the board.
The full localisation process is as follows:
1. A project manager is appointed per language.
2. The localisation project manager retrieves the elements to be localised. These include:
- the ingames [text or dialogue components 'embedded' in the game],
- the audio script [dialogues and onomatopoeia],
- various accompaniments generally referred to as 'packaging' [box, back of box, CD face, user manual, user's guide, vouchers, etc.]
3. The localisation project manager collects any applicable specifications.
4. The translation-localisation environments are set up and tested (choice of platform, hardware, software, operators, and resources).
5. Batches are made up if applicable.
6. Components are sorted out and made into sets:
- ingames,
- audio script,
- accompaniments.
7. The localisation project manager creates the master schedule.
8. The localisation project manager recruits the translators with the required skills:
- To localise the game, depending on the style of the game, platform type and working languages;
- To translate the accompaniments (the skills are those required by any type of translation except if the 'accompaniments' include a Web site requiring special skills).
9. The translators-localisers analyse the structure and functions of the game and/or the contents of the accompanying documentation. Special attention is given to the characters and script of the game. The translation-localisation project (constraints, modes, options, etc.) is specified.
10. The translation-localisation project is validated.
11. The localisation project manager [or the translators-localisers] prepare(s) the versions for localisation and/or translation (tagging, conversions, terminology, phraseology, memories, and documentary study if applicable).
12. [as the case may be] Support versions are created.
13. The translators carry out the translation (including subtitles if applicable).
14. The translators check, proofread, revise (quality-control) the translation.
15. If applicable, the localisation project manager reassembles all translated material.
16. The sound-recording studio records the localised audio scripts.
17. The developers integrate the localised ingames and the voice and music soundtrack into the game.
18. The developers integrate the translated elements of packaging onto their respective media.
19. The localisation department receives a version of the game that includes the localised ingames and scripts.
20. The localisation department tests the localised version of the game, meaning it:
- Checks all localised elements,
- Controls linguistic-stylistic quality
- Checks there is a perfect fit between scripts, ingames and images
- Controls functional quality
- Tests the ergonomics of the game
- Qualifies the result of the translation-localisation
21. The tested version of the game if sent back to the designers/developers, with all bug reports. The designers/developers make all corrections and amendments and finalise the game (sometimes after a new round of quality controls).
22. A master is created and the packaging is printed.
Note: The localisation department is also called on to translate and localise anything related to the game itself and particularly any promotional material, information for the press and media, contents of sites that are set up for marketing and information purposes.
c) Promotion and sales
Once the localised versions have been integrated, the packagings are printed, the CDs or DVDs are burnt and the boxes created. Advertising and marketing campaigns are launched. Sites dedicated to the game are activated and media campaigns are launched.
2.4.1.4 Translators and/or localisers?
At that stage, there is one question outstanding: what exactly do translators do when it comes to localisation.
The obvious answer is that translators do the translating. What is for sure is that they translate all of the accompanying documentation (online help, user guide, packaging, advertising campaign, etc.) As for the rest, they also transfer and adapt the linguistic components of Web sites, software packages, and videogames. And, naturally enough, they will also be expected to take their share (the linguistic- functional one) of quality control. The translators thus normally carry out the steps highlighted by the shading in all three localisation processes above.
So far, there is nothing new to their activity. Except that their translations are 'instrumental', meaning they are obviously designed as (documentary) 'tools' in their own right or as parts of products in which they are embedded) and must therefore be fully functional. Hence the importance of testing [which is turning out to become a full-blown job in itself] and the stringency of functional quality requirements: any shortcoming or defect soon becomes blatant. At the same time, the fact that the translated material is embedded in a particular medium entails particular constraints, raises specific problems, and calls for new strategies; whence the claim that this is not simply translation.
But there is more to it than translating. Given the skills required, translators may go for a bigger share of the cake by providing a bigger share of the total localisation service. And many will want to acquire the extra skills to that purpose.
In the case of software localisation, translators will translate all of the material accompanying the software package (Readme file, installation guide, user guide, instructions manual, online help, etc.) as well as the linguistic elements embedded in the software (menus, interfaces, commands, databases, etc.). They might also do the testing and quality control. But the extra skills required to increase their share of the overall localisation service are not easily come by. They may disassemble and reassemble the application, but, barring very few exceptions, it is unlikely they will tamper with the code.
In the case of Web site cloning or pseudo-cloning, translators will translate and adapt all linguistic components and contents as well as control quality - as usual. But, this time, they may do a lot more. They may in fact, create or adapt the architecture, do the infographics, reintegrate the contents, create the links, do the online QC, and so on. This means they will write or rewrite part of the code and maybe even redefine the colour chart or the CSS. Needless to say, they may also decide to 'localise' everything technical and functional. 'Localisers' thus come somewhere between the ordinary translator and the webmaster. As a matter of fact more and more translators are in charge of creating or 'localising' multilingual Web sites on their own - without the help of any other operator.
Similarly, translators involved in videogame localisation will translate all of the material accompanying the videogame (packaging, helps, Web site contents, guides, etc.) and the ingames. They will also normally be called onto do the testing, which is particularly critical with videogames, but they will normally not have the technical skills required for any further component of the localisation process.
We may thus consider that linguistic localisers (translators) are people who translate (meaning, of course, that they adapt) the linguistic component of the product (software, videogame, Web site) to be localised and whatever 'tools' and documentary material go with that product, for whatever purpose. In that perspective, linguistic-cultural localisation is translation in a special situation and context. But linguistic-cultural localisation more often than not extends into other aspects and phases of localisation, to an extent depending on the availability of the extra skills required. It extends as a matter of course into quality control and it is no surprise that translators turn into OQCE's (online quality control experts). It also extends into other skilled operations. In most cases, translators who specialise in localisation can claim they have become more than 'mere' translators.
As a rule, translators who have definitely shifted to the localisation markets rapidly take on managerial responsibilities. These range from management of the sound recording part (in film dubbing) to global localisation project management (in all situations and types of localisation). This ranges from managing part of the general process (e.g. the sound recording management function that translators take on in videogame localisation) to the global management of large-scale localisation projects of all natures and types. What actually happens is the individual translator's choice and depends on circumstances... and skills.
2.4.2 Media translation
Media translation is another category of translation - which could just as well go by the name of localisation. It includes voice-over, subtitling and overtitling, and dubbing but also such new techniques as media description.
2.4.2.1 Voice-over translation
Voice-over is a film technique in which a person not seen on screen narrates the action, presents his or her feelings, or summarizes events.
Voice-over can be in the original language. In fact, the technique is most often used to make a film understandable to an audience that does not know the language, without having to either subtitle or dub that film.
Voice over translation is therefore either the translation of the voice-over soundtrack in the original or the 'adaptation' of the script and dialogue to produce a localised voice-over soundtrack. Voice-over translations condense the information conveyed by the soundtrack. The translation must obviously accurately reflect the original message while fitting in with what is being shown on screen. The voice-over commentary therefore needs to be perfectly synchronised with the corresponding visual sequences. Unlike dubbing, where lip synching and camera synchronisation are essential, there are no other particular constraints applicable to this kind of translation.
2.4.2.2 Captioning a) Subtitling
Subtitling is the captioning of the translation of the spoken dialogue in the original soundtrack. Except if the translator receives a ready-for-subtitling version and just needs to convert the script into subtitles, subtitling is a rather complex operation that varies according to available technologies in a context where things change ever so fast.
The shaded parts identify what the 'subtitler' does as a matter of course. Under the influence of technological changes, we have moved from a situation where the translator translated the script, with the help of a time-coded and 'detected' version of the film, to a situation where the subtitler does everything from A to Z - from detection to simulation and sometimes even mastering - all on the same workstation.
The subtitling process is as follows:
1. The translator/subtitler gets the tape or copy of the documentary, advert, movie, cartoon, etc. and the script.
2. The translator/subtitler gets the specifications
3. The translator/subtitler views the video.
4. The translator/subtitler sets up the subtitling environment.
5. The translator/subtitler creates a version for subtitling by:
- transferring the material onto a convenient medium (e.g. converting the film to video with time-codes - chronological cues that make it possible to identify frames and therefore know exactly when a dialogue element starts and ends),
- converting the material into a usable format (e.g. digitizing the video or film so that it can be processed by means of a particular subtitling software)
6. The translator/subtitler sets up the version for subtitling in the subtitling environment.
7. The translator/subtitler creates the version for translation through detection or cueing.
"Detection" or "cueing" consists in spotting the start (Time-code in or TC in) and end (Time-code out or TC out) of the dialogues as well as the camera shifts and the title cards or captions. Detection provides an opportunity to check the typescript against the actual dialogues. The translator can thus:
- mark the script with the beginnings and ends of the dialogue sequences and the screen shots,
- segment the dialogues and cards or captions,
- use a dedicated software package to set up the subtitle matrices which, in sync with the images, give the number of characters for each subtitle.
The time-code in and time-code out for each item of dialogue determine the duration (reading time) of each item and its position.
8. The translator reads the presentation of the characters, the story and the script.
9. The translator creates the subtitles (translates). This is usually referred to as 'adapting' the subtitles. The main limitation here is the speed at which the viewer can read the subtitles, compared with the speed of speech, which means that the subtitles have to be condensed accordingly.
10. The translator produces a subtitle file or keys the subtitles in if the software so warrants.
11. The translator proofreads and checks the subtitle.
12. The translator makes any necessary correction.
13. Simulation [a sort of trial run where the subtitles are integrated into the videotape] provides the opportunity to view the subtitles in real time and to check that they 'fit in', are accurate, visible, readable, 'good' and efficient and do not contravene any of the rules of the art [e.g. no shot change overruns]. The simulation phase is usually carried out in the presence of all the various people involved in the making of the film or video (director, producer, etc.). Simulation may include synchronisation of the copy to be subtitled and the subtitled copy (synchronisation is checked shot by shot, changes in the size or position of the subtitles may be made, unreadable subtitles are repositioned, etc.)
14. If need be, the translator corrects, adapts, modifies the translation, in which case a new simulation will be carried out.
15. The subtitles are validated.
16. The subtitles are transferred to film according to the chosen technique (e.g. burning, engraving, other) and a master copy is created.
17. If required, the film is specially processed to ensure optimum subtitle quality.
18. The final product is viewed and passed for release once the quality is approved
Note: Live subtitling for the deaf and hearing-impaired does not require translation as the aim is to display a written version of dialogue or voice over commentary. This may imply some degree of simplification and the loss of specific features such as regional accents. The subtitles are displayed according to a conventional colour code so that viewers know which words are meant to be dialogue, internal monologue or voice-over commentary.
b) Overtitling
Overtitling refers to the technique used in some operas and theatres, where the actors' or singers' words are displayed above the stage. This is the 'live' equivalent of subtitling, except that the words must be synchronised manually with the action taking place on stage. The overtitler will obviously use the libretto and, whenever possible, existing translations of the work, but the titles have to be adapted to the
particular production and stage directions (for instance, the director may require certain cuts in the original work). The overtitles may also have to fit particular actors' or singers' personalities (rather flamboyant overtitles may not fit a rather wooden performance for instance, unless the director is seeking a deliberate effect). Duos and choral parts present particular difficulties as the different parts must remain clearly identified though contrasting colours may come in handy.
Overtitles may be likened to the contents of a PowerPoint presentation displayed item by item on a specially designed 'linear screen'. All that has to be done is create the overtitles in advance and then display them as the vocal action proceeds. The source is the libretto or the text itself.
Live overtitling requires a lot of mental agility and typing dexterity, plus special software functions warranting immediate automatic display on completion of each overtitle.
2.4.2.3 Dubbing
In dubbing, the creation of a localised version to replace the original version is organised in the following sequence of operations, many of which are carried out by the translators or 'authors' as they are usually called.
Today, in most cases, translators-adapters (authors) normally take care of the various steps and stages highlighted by shading in the list below. They may also assume managerial responsibilities acting, as happens with videogame localisation, as assistants to the sound-recording manager or the overall project manager.
The process is initiated by a distributor buying the right to produce a foreign- language version. It begins with the hiring of a dubbing supervisor or director.
1. Onset. The dubbing director receives a master of the audiovisual product that will be dubbed. For the sake of simplicity and convenience, the master may be duplicated on a video tape.
2. Team setup. The dubbing director sets up the team, including one specialist at least for each of the following stages:
- detection,
- adaptation,
- calligraphy (if dubbing done manually),
- scheduling of artists and comedians,
- recording,
- mixing,
- layback.
3. Transcription. If the original script is not available on paper, a transcript is made.
4. Reception. The translator-adapter-writer receives the medium for dubbing, together with the script and any relevant accompaniment.
Note: In some cases, the dubbing director receives a translation of the script. That translation has been done by 'ordinary' translators who did not have to pay any attention to synchronisation: they were simply requested to do a faithful translation of the original. It is then the dubbing team's responsibility to adapt that translation to comply with the requirements of the film situations and of synchronisation (and then to synchronise it).
5. Brief. The translator-adapter-writer obtains the specifications.
6. Viewing. The translator-adapter-writer views the medium for dubbing.
7. Environment. The dubbing environment (platform, hardware, software and various resources) is set up.
8. Version for dubbing. A version for dubbing is set up to accompany the script. This means:
- transferring the material on to a working medium (e.g. time-coded VHS),
- converting the material into the proper format (e.g. digitising and/or adapting the material to the format requirements of the software used).
9. Setup. The version for dubbing is set up in the dubbing environment. This means either:
- Loading the image tape into the virtual rythmo tape.
- Loading a tape into the rythmo tape projector [a projector showing a line of text or time reference (time coding) at the bottom of the screen, scrolling in sync with the main projector thanks to a time reference converter] in case of manual dubbing.
10. Detection. This consists in detecting (by their time codes) and marking the following on the tape:
- 'loops' - brief (15 to 50 seconds) excerpts from scenes,
- shot changes,
- sentences in and sentences out,
- breathing noises, laughter, shouts,
- movements of the lips as well as mouth opening and closing movements on which to synchronize the dialogues since the viewer would be dismayed by discrepancies between what he sees and what he hears - meaning a labial in the localised version must be substituted for a labial in the international version.
Detection also entails identifying (and marking) each character's dialogue so that everyone knows who says what, where, in which time span. All of the dialogues spoken by a given character thus appear on the same line on the rythmo tape and are uniformly colour coded.
11. Translation-adaptation of dialogue and other elements in the script. This means:
The adapter rewrites the dialogues directly onto the time-coded image tape, making sure everything is in sync. The dubbing software automatically generates the calligraphy, the script, and the tabular representation of the dialogues for the respective characters.
If the software is not available, the adapter uses a word processor to create one file indicating the TC In and TC out for each tape element.
12. Proofreading and quality control, with required corrections and changes and conformity checks.
13. Simulation. The translator-adapter reads the translation aloud as it is displayed on the rythmo tape to make sure everything is in sync.
14. As the case may be, reintegration of the dialogue file into the rythmo tape.
15. If dubbing is carried out manually:
a. Calligraphy [manual transcription of the dialogues onto the tape] or export of the text of the dialogues.
b. Creation of the work schedules.
16. The result is sent to the recording studio so that the actors/comedians can record the dubbed version. This can be done by exporting the dialogue file or sending the rythmo tape with the translated dialogues and the character parts.
Дата добавления: 2015-09-29; просмотров: 23 | Нарушение авторских прав
| <== предыдущая лекция | | | следующая лекция ==> |