- General Information
- Connecting Third-party Systems
- crossConnect for content systems
- crossConnect for External Editing
- Purpose and usage
- Requirements
- Implementation
- Across XLIFF format
- Across-specific Extensions
- <xliff> Element Attributes
- <file> Element Extensions
- <trans-unit> Element Extension
- Paragraph States
- Paragraph State Flags
- <source> and <target> Element Content
- <bpt> Element Attributes
- <ph> Element Attributes
- <x> Element Attributes
- Across-specific Properties
- Analysis Results
- Sample Files
- Across XLIFF - import, export and segmentation
- Context information
- Exporting best matches in Across XLIFF
- Hyperlinks to XLIFF
- Secure file handling with C#
- Secure file handling with JAVA
- Workflow and vendor configuration
- Sample code - Integrated solution
- Across XLIFF format
- Generic File Connector
- Display Texts
- APIs
- APIs - Technology
- crossTank API v1
- crossTank API v2
- crossTerm API v1
- crossTerm API v2
- crossAPI SI
- Requirements
- Function Return Types
- crossAPI SI and Java
- List of Objects in crossAPI SI
- Sample - transferring checkout files via FileManager
- Sample - VBS
- Text Preprocessing API
The Across solution in detail
Let's see in detail, how the Across solution for texts with limited length works.
Let's assume Across has extended its product line by the washing machine crossWash v1.
crossWash v1 has a display which displays different text areas dependent on the current mode.
- Below, you can see four different modes with the four text areas for headlines, lists, cells, and messages.
- A headline is a simple 360x50 pixel text box with the bold font Comic Sans MS 34 pt.
- Lists and Cells are similar, but have different text box dimensions and no bold font.
- A message is a multi-line text box with two different styles and an automatic word warp.
Preparations
The content of the displays has to be available in the Across display text format.
In our example, we use an dtxml file which you can download from crossWash.
- Steps to be done:
- First, you should define the dimensions of the different areas. This is done in the <sizeinfos> area of the file.
IDs and the word wrap setting are also properties of the sizeInfo elements. - The next step is to define style information, i.e. which fonts can occur in the display. This is done in the <paragraphStyles> area.
- Finally, you define the content and associate it with the size and style information. Furthermore, you can add comments and ID as context information for the translators. This is done in the <paragraphs> area.
- Then you can go on creating a project with the document.
The translation environment
After you created the project and assigned it to a user, you can see how it looks like for the translator.
The translation environment in crossWeb offers everything a translator needs:
The crossView to the left:
In the document tree, IDs of the display text strings can be shown as context information.
- Other tabs offer
- Quality checks
- Attachments (screenshots, guidelines,...)
- Paragraph state-based navigation
- Search and replace
- Progress information
- In the center, the Source View on top and the Target Editor with the real-time preview below it :
- The Source View shows a source text to the left and a translated text to the right. Below the source paragraphs, comments can be shown. This is especially important if the context is crucial for a correct translation. In the example, the German word "Wollwäsche" is ambiguous: it could mean either a piece of laundry or a washing process.
- For the source and target texts, green and red bars show whether they fit into the display.
- The color of the text entered in the Target Editor changes to red as the text exceeds display boundaries.
- The real-time preview shows the display boundaries and the translated text in the specified font. It is an image which is rendered on the server, so that the translator does not need the font to be installed on his machine. The display text box changes from green to red as the text exceeds the limits.
At the bottom, translation memory matches are displayed.
To the right, search results from the terminology database are displayed. Misnomers and preferred terms are highlighted. The matches in the source text are also marked with red overlines above the terms.
In the screenshot, the font "Comic Sans MS" is not available on the PC where the browser is running. For that reason, the Source View and the Target Editor are using a fallback font. The real-time preview on the right to the Target Editor shows the text in the real font because it is an image which was created on the server and sent to the browser.
When storing or switching the paragraph, the quality assurance will detect a text bounds error.
When trying to finish the task, the user will see the summary with all quality errors at the latest. In the example here, the QM check is mandatory, so the task cannot be finished by the translator as long as a text bound error exists. Thus, the project manager can ensure that the text he receives fits into the text areas of the display.
The QM checks are properties of workflows which are again properties of documents. More information on the QM checks is available in the Across user manual.
The error disappears after adjusting the text to fit into the boundaries.
Also displays with multiple lines are supported. crossWeb checks whether the text fits horizontally and vertically.
With the auto-wrap setting, you can activate an automatic line break.
All features illustrated above are also available for displays with different line lengths.