I really like this image created by DALL·E of a man… maybe a businessman… on a wall, putting down his newspaper and reaching down to offer help to the worker with a ladder. Created with only this prompt – “Helping the Help in the style of Richard Estes.” When we read about how ChatGPT is “only” an advanced autosuggest we really need to think about how it must have some understanding of what was previously said to be able to predict the suggestion. DALL·E really demonstrates this well because it had to have enough of an understanding of the concept of help in terms of not only helping, but also the use of the word help as someone who could be employed to help (in this case maybe a caretaker or janitor)… and then think about how this could be represented as an image, and in the style of a photorealist painter I mentioned by name. Then do all that in a matter of seconds. Quite astonishing really.
But I’m not here to write about this kind of help! A couple of years ago I qualified as a technical writer as part of a Masters degree I undertook, so in theory I ought to be capable of creating help documentation that comes up to a recognised standard in terms of how technical communication is carried out. In fact tekom says this: “Technical writers make modern technology comprehensible.” When I think about help documentation that simple definition seems to say it all. However, technical documentation for online help can sometimes be less than helpful for a variety of reasons… for example:
- Complexity of the subject
- Lack of clarity
- Incompleteness
- Outdated information
- Poor organization
- Jargon and technical terms
- Lack of examples or use cases
- Insufficient visual aids
- Inadequate focus on the user
- Limited resources and time constraints
There can be many reasons for each of these problems, and I’m not here to judge or be critical of any particular documentation, but I am interested to see how it could be improved when you find something that isn’t as clear as you need. One way, and this is something we can all do, is to use AI like ChatGPT, to improve the material we read so it helps us with a better understanding of what we’re trying to learn.
I started to look at this after trying to use the online help to provide a user with some information to help explain about some of the options in the XLIFF filetype. In particular, these options in Trados Studio:
Clicking on the help takes you, at the time of writing to this location. This page contains some information about all the settings for the XLIFF filetype, but scrolling down a little I can find this part which is relevant to the “Segment status mapping” node in Studio that I’m interested in:
Now, I’m not going to critique the information in here so let’s just say it’s not optimal for my understanding of how to use the options in support of this filetype. So let’s start by just seeing what ChatGPT knows about this. So I just copy this section into ChatGPT and ask it to elaborate on the provided text:
The response wasn’t bad… at least it was already somewhat more informative:
The help documentation you provided explains the XLIFF filetype settings in Trados Studio. XLIFF, or XML Localization Interchange File Format, is a standardized file format used to manage the translation process. In Trados Studio, the Segment status mapping page allows you to control the behavior of segments when opening and saving XLIFF files. Here’s a more detailed explanation of each setting:
- File opening: This setting establishes a correspondence between the XLIFF status and the Studio status columns based on the values you choose for each column. When opening a file, if the XLIFF status value matches the Studio status value set for that segment, the target content will be displayed as locked. Locked segments cannot be edited, ensuring that the translation remains unchanged.
- File saving: Similar to the File opening setting, this option creates a correspondence between the XLIFF status and the Studio status columns based on the selected values for each column. When saving a file, if the Studio status value matches the XLIFF status value set for that segment, the target content will be displayed as locked content in the saved XLIFF file, preventing any changes.
- Segment locking: This setting enables you to lock segments with a specific status. By checking the status, you trigger a lock operation on those segments, making them uneditable and ensuring their translations remain unchanged.
- Map state-qualifier attribute values when reading file: This setting creates a correspondence between segment states in the Studio Editor when opening the XLIFF file. It helps maintain the segment states, such as “approved,” “rejected,” or “needs review,” so that translators can easily understand the status of each segment and act accordingly.
- Map state-qualifier attribute values when writing file: This option creates a correspondence between segment states in the target file when saving the XLIFF file. It ensures that the segment states are accurately reflected in the saved XLIFF file, facilitating a smooth translation process across different platforms.
By configuring these settings in Trados Studio, you can manage the translation workflow more efficiently, maintain segment states, and protect specific translations from unintentional changes.
There some parts that might be a bit misleading but what I’m really missing is an understanding of how these settings influence the behaviour of a file in Trados Studio. I’m pretty clear about the “Segment status mapping” and the “Segment locking” as this improved explanation coupled with me clicking on the dropdown in Trados Studio for these options makes this fairly obvious… although the help documentation does have room for improvement there too. But I’m not at all clear on how to work with the “State-qualifiers”… in fact I may not even be sure what they are! So my first task is to find this out and to do that the beginning of the page I get to in the online help tells that these settings are for working with files compliant with the OASIS XML Localisation Interchange File Format (XLIFF) standard version 1.1 or 1.2. So I google that and find this document:
http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html
I search that page for “state-qualifier” and find a neat section related to this topic. Now I know this:
State-qualifier – Describes the state of a particular translation in a <target> or <bin-target> element.
There is also a very neat table describing all the possible values and their descriptions. Very helpful… but if I had a test file it would be even better as I could test how Trados Studio handles this and actually see the effect of each value when using the “State-qualifiers” options in Trados Studio. Maybe ChatGPT can help with this? So I ask this question and paste the entire table from the specification into the prompt:
I asked it to create a sample file for me with 14 translation units, as there are 14 values in the table. In seconds I’m obliged with this:
<?xml version="1.0" encoding="UTF-8"?>
<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2">
<file source-language="en" target-language="fr" datatype="plaintext" original="file.ext">
<header>
<tool tool-id="chatgpt" tool-name="ChatGPT" tool-version="1.0" />
</header>
<body>
<trans-unit id="1" xml:space="preserve">
<source>Hello, world!</source>
<target state-qualifier="exact-match">Bonjour, le monde !</target>
</trans-unit>
<trans-unit id="2" xml:space="preserve">
<source>Goodbye, world!</source>
<target state-qualifier="fuzzy-match">Au revoir, le monde !</target>
</trans-unit>
<trans-unit id="3" xml:space="preserve">
<source>Thank you!</source>
<target state-qualifier="id-match">Merci !</target>
</trans-unit>
<trans-unit id="4" xml:space="preserve">
<source>Please</source>
<target state-qualifier="leveraged-glossary">S'il vous plaît</target>
</trans-unit>
<trans-unit id="5" xml:space="preserve">
<source>Good morning</source>
<target state-qualifier="leveraged-inherited">Bonjour</target>
</trans-unit>
<trans-unit id="6" xml:space="preserve">
<source>See you later</source>
<target state-qualifier="leveraged-mt">À plus tard</target>
</trans-unit>
<trans-unit id="7" xml:space="preserve">
<source>How are you?</source>
<target state-qualifier="leveraged-repository">Comment ça va ?</target>
</trans-unit>
<trans-unit id="8" xml:space="preserve">
<source>What's your name?</source>
<target state-qualifier="leveraged-tm">Comment tu t'appelles ?</target>
</trans-unit>
<trans-unit id="9" xml:space="preserve">
<source>Good night</source>
<target state-qualifier="mt-suggestion">Bonne nuit</target>
</trans-unit>
<trans-unit id="10" xml:space="preserve">
<source>I like apple</source>
<target state-qualifier="rejected-grammar">J'aime pomme</target>
</trans-unit>
<trans-unit id="11" xml:space="preserve">
<source>Where is the library?</source>
<target state-qualifier="rejected-inaccurate">Où est la piscine ?</target>
</trans-unit>
<trans-unit id="12" xml:space="preserve">
<source>It's a beautiful day</source>
<target state-qualifier="rejected-length">C'est un beau</target>
</trans-unit>
<trans-unit id="13" xml:space="preserve">
<source>Have a great weekend!</source>
<target state-qualifier="rejected-spelling">Passez un excellent weekand !</target>
</trans-unit>
<trans-unit id="14" xml:space="preserve">
<source>What time is it?</source>
<target state-qualifier="tm-suggestion">Quelle heure est-il ?</target>
</trans-unit>
</body>
</file>
</xliff>
I put the whole file in here as I think it’s really helpful for anyone who would like to test it… and it only took me a few seconds to create anyway! I can now use this XLIFF and test in Studio to see what happens!
This is much better and now it’s become quite clear for me. I even like that the sample file created by ChatGPT used translations relevant to the reason for the stats-qualifier value! Rejected grammar, accuracy, length and spelling… pretty smart especially as I didn’t even ask for it to be that clever!
But then I think… what happens if I also map the segment statuses? Which takes precedence…is there even a precedence? So first I do the same operation and just look at the mappings. I can find a similar table in the specification here:
http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#state
I repeat the process I used before to have ChatGPT create a sample file for me:
The result is a slightly smaller file this time as there were only 10 different states. It actually did it wrong the first time and it placed the state attributes into the trans-unit element which is incorrect… I know this because the specification says this:
State – The status of a particular translation in a <target> or <bin-target> element.
So I just asked ChatGPT to do it again and make sure the state attribute was in the target element… which it duly obliged. I mention this because the point I’m making is that this is still a tool that can help even if you do have to make some corrections… just don’t blindly accept everything it’s telling you as you may not get the results you expected. I also asked ChatGPT why it made this mistake but it offered no explanation, only an apology and then created the corrected file:
<?xml version="1.0" encoding="UTF-8"?>
<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2">
<file source-language="en" target-language="fr" datatype="plaintext" original="example.txt">
<header></header>
<body>
<trans-unit id="1">
<source>Welcome to our website!</source>
<target state="final">Bienvenue sur notre site !</target>
</trans-unit>
<trans-unit id="2">
<source>20% discount on selected products</source>
<target state="needs-adaptation">20 % de réduction sur les produits sélectionnés</target>
</trans-unit>
<trans-unit id="3">
<source>Our store is located at 123 Main St.</source>
<target state="needs-l10n">Notre magasin est situé au 123 rue Principale.</target>
</trans-unit>
<trans-unit id="4">
<source>Call us at 123-456-7890.</source>
<target state="needs-review-adaptation">Appelez-nous au 123-456-7890.</target>
</trans-unit>
<trans-unit id="5">
<source>We ship to the USA and Canada.</source>
<target state="needs-review-l10n">Nous livrons aux États-Unis et au Canada.</target>
</trans-unit>
<trans-unit id="6">
<source>Sign up for our newsletter.</source>
<target state="needs-review-translation">Inscrivez-vous à notre lettre d'information.</target>
</trans-unit>
<trans-unit id="7">
<source>Visit our blog for the latest news.</source>
<target state="needs-translation"></target>
</trans-unit>
<trans-unit id="8">
<source>Check out our new collection.</source>
<target state="new"></target>
</trans-unit>
<trans-unit id="9">
<source>Follow us on social media.</source>
<target state="signed-off">Suivez-nous sur les réseaux sociaux.</target>
</trans-unit>
<trans-unit id="10">
<source>Contact our customer support.</source>
<target state="translated">Contactez notre support client.</target>
</trans-unit>
</body>
</file>
</xliff>
But it was still similarly simple and ChatGPT created a useful file in a few seconds that I can also test. I don’t change any of the defaults in Trados Studio (but I do remember to uncheck the boxes for the “state-qualifiers”) since this filetype is based on compliant XLIFF 1.2 and this surely is one! The result being:
This is also very useful because even though I had a reasonable understanding of what to expect it’s much better to be able to visualize it. Now that I’ve seen both I can take a look at which takes precedence. To do this I think I need some sort of baseline so I can just add the state=”translated” state to each of the 14 translation units in my first example and see how this changes things. I could do this with regex… but I can just as easily copy the file ChatGPT created for me into the prompt and ask it to add the state=”translated” for me. Here’s the file just in case you’d like to test it yourselves:
<?xml version="1.0" encoding="UTF-8"?>
<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2">
<file source-language="en" target-language="fr" datatype="plaintext" original="file.ext">
<header>
<tool tool-id="chatgpt" tool-name="ChatGPT" tool-version="1.0" />
</header>
<body>
<trans-unit id="1" xml:space="preserve">
<source>Hello, world!</source>
<target state="translated" state-qualifier="exact-match">Bonjour, le monde !</target>
</trans-unit>
<trans-unit id="2" xml:space="preserve">
<source>Goodbye, world!</source>
<target state="translated" state-qualifier="fuzzy-match">Au revoir, le monde !</target>
</trans-unit>
<trans-unit id="3" xml:space="preserve">
<source>Thank you!</source>
<target state="translated" state-qualifier="id-match">Merci !</target>
</trans-unit>
<trans-unit id="4" xml:space="preserve">
<source>Please</source>
<target state="translated" state-qualifier="leveraged-glossary">S'il vous plaît</target>
</trans-unit>
<trans-unit id="5" xml:space="preserve">
<source>Good morning</source>
<target state="translated" state-qualifier="leveraged-inherited">Bonjour</target>
</trans-unit>
<trans-unit id="6" xml:space="preserve">
<source>See you later</source>
<target state="translated" state-qualifier="leveraged-mt">À plus tard</target>
</trans-unit>
<trans-unit id="7" xml:space="preserve">
<source>How are you?</source>
<target state="translated" state-qualifier="leveraged-repository">Comment ça va ?</target>
</trans-unit>
<trans-unit id="8" xml:space="preserve">
<source>What's your name?</source>
<target state="translated" state-qualifier="leveraged-tm">Comment tu t'appelles ?</target>
</trans-unit>
<trans-unit id="9" xml:space="preserve">
<source>Good night</source>
<target state="translated" state-qualifier="mt-suggestion">Bonne nuit</target>
</trans-unit>
<trans-unit id="10" xml:space="preserve">
<source>I like apple</source>
<target state="translated" state-qualifier="rejected-grammar">J'aime pomme</target>
</trans-unit>
<trans-unit id="11" xml:space="preserve">
<source>Where is the library?</source>
<target state="translated" state-qualifier="rejected-inaccurate">Où est la piscine ?</target>
</trans-unit>
<trans-unit id="12" xml:space="preserve">
<source>It's a beautiful day</source>
<target state="translated" state-qualifier="rejected-length">C'est un beau</target>
</trans-unit>
<trans-unit id="13" xml:space="preserve">
<source>Have a great weekend!</source>
<target state="translated" state-qualifier="rejected-spelling">Passez un excellent weekand !</target>
</trans-unit>
<trans-unit id="14" xml:space="preserve">
<source>What time is it?</source>
<target state="translated" state-qualifier="tm-suggestion">Quelle heure est-il ?</target>
</trans-unit>
</body>
</file>
</xliff>
When I open this file in Trados Studio making sure I have again checked the options to map the “state-qualifiers” I see this:
Comparing the two and it seems clear that the “state-qualifiers” take precedence where applicable. Segments #10, #11, #12 and #13 have all retained the “Translation Rejected” status which makes sense since you shouldn’t be able to have a confirmed translation that had rejected errors in it. Another quick test, this time by simply search replacing the state=”translated” attribute with state=”needs-review-l10n” and this time it’s clear that the “state” takes precedence:
So then I went back to ChatGPT and sought some clarification by asking it “Can you explain which would take precedence, the “state” attribute or the “state-qualifier” when both are used in a target element?”. This may seem obvious to anyone familiar with XLIFF but given we have these controls in Trados Studio and I am clearly allowed to do something odd by creating a file that contained possible conflicting information between these attributes I think an explanation would be useful. The answer was this:
When both “state” and “state-qualifier” attributes are present in the target element, it’s important to understand the difference between them:
- The “state” attribute defines the general translation status of the target element, such as “translated,” “needs-translation,” or “final.”
- The “state-qualifier” attribute provides additional context or information about the state, such as “needs-review-l10n,” “needs-review-adaptation,” or “signed-off.”
In case both attributes are used in a target element, they complement each other and do not conflict. There is no precedence of one over the other. Instead, they provide more granular information about the translation status.
For example:
<target state=”needs-review-translation” state-qualifier=”needs-review-l10n”>…</target>
In this example, the “state” attribute indicates that the translation needs review, while the “state-qualifier” attribute specifies that it needs review specifically for localization aspects. Both attributes work together to describe the translation status more accurately.
So, the conclusion I can draw from this is that Trados Studio doesn’t expect to receive an XLIFF where these attributes conflict, but when it does it will try to take a sensible decision and ensure that the segment status represents the more plausible status based on the situation in each case. I could test each one for my own benefit if I was documenting all of this to create an improved version of the online help, but this is probably enough information for me in being able to understand how these options work and why.
But what can I conclude from this exercise as a whole?
Conclusion
For the User
Using a tool like ChatGPT to help with understanding and working with this particular online help page has proven to be beneficial in several ways:
- Quick and informative responses: ChatGPT can provide instant responses to questions or concerns about the topic, helping you grasp concepts faster and more efficiently.
- Custom examples: ChatGPT can generate tailored examples based on your specific requirements, which can aid in better understanding and visualization of how different attributes and settings work in practice.
- Iterative learning: By engaging in a back-and-forth conversation with ChatGPT, you can refine your understanding of the subject and address any misconceptions or confusion along the way.
- Supplementing existing knowledge: ChatGPT can complement your existing knowledge and serve as a convenient source of information for clarification or deeper understanding.
However, it’s important to keep in mind some limitations and considerations while using a tool like ChatGPT:
- Possibility of errors: ChatGPT, while advanced, is not infallible and can sometimes provide incorrect or incomplete information. It’s essential to cross-verify the information received from the AI with reliable sources or your own understanding.
- Need for guidance: ChatGPT may require specific instructions or prompts to produce the desired output. You may need to rephrase your questions or provide additional context to get the most relevant and accurate response.
In conclusion, using a tool like ChatGPT to assist with enhancing your understanding of technical topics like this can be highly beneficial. It can serve as a valuable resource for quick information, custom examples, and iterative learning. However, it’s essential to be aware of its limitations and verify the information received to ensure accuracy and reliability.
For the Technical Writer
ChatGPT can probably be useful to a Technical Writer too… especially one like me who “in theory ought to be capable” of writing good help documentation:
- Content generation: ChatGPT can help generate content quickly, providing initial drafts, ideas, or examples that the writer can then refine and edit.
- Editing and proofreading: ChatGPT can provide suggestions for improving clarity, grammar, or style in existing documentation.
- Explaining complex concepts: ChatGPT can help simplify and explain complex concepts in a more user-friendly manner.
- Answering questions: ChatGPT can help clarify doubts or provide additional information about the subject matter.
- Generating examples: ChatGPT can generate sample code, files, or illustrations to better explain a concept or procedure.
However, it’s important to note that ChatGPT is an AI tool, and its output should be carefully reviewed and edited by the Technical Writer to ensure accuracy, relevance, and consistency. The AI is not perfect, and it may sometimes generate incorrect or irrelevant information. The Technical Writer should always verify the information provided by the AI and apply their own expertise and judgment to create high-quality documentation.
But all in all a very useful tool in yet another way!
