YAML Ain’t Mowing Lawns
Saturday mornings, if we’re not away for the weekend, inevitably mean trying to fit in the household chores with the things I’d rather be doing… playing around on my laptop doing something!
The age of AI has completely changed that to a large extent and is yet another example of how much AI is infiltrating our lives… depending on how much you try to embrace it. Like many people I reach for Claude or Gemini on my phone whenever I have a question I’m seeking an answer for. I don’t google it anymore even though Google makes an AI summary available with every search. I like to use an AI chat because it stays on point, doesn’t shower me with irrelevant adverts or results and I can more easily interact with it in all sorts of ways by using other features on my phone. I have to work hard not to become overly reliant on it because I simply don’t want to… but the temptation is there and that pull gets stronger all the time, especially as so many things I would have had to study long and hard for are now available with little effort on my part.
One thing I had steered clear of so far was allowing Claude or any other AI tools to actually interact with my laptop. Maybe I was not seeing the benefits that others are already using… maybe I just felt that was a step too far to let something I have no control over that far into my life. But a couple of weeks ago I used Claude Code for the first time to update a plugin I vibe-coded the old fashioned way (funny that things are moving so fast I even see an old fashioned way to vibe code!) file by file, feature by feature and built it with the help of Claude, but within Visual Studio where I pressed the buttons and at least had to learn how to operate the application! Claude Code is different… with Claude Code I just need to build a specification for what I want, create folders for the code and the documentation… point Claude Code to it and it will pretty much get on with it and build the applications itself with little involvement from me!
The update I worked on was upgrading Localyzer Connect for Trados to support the new Trados Studio – 2026 Release. I gave Claude Code a spec., pointed to the developer documentation, and only a few minutes later the upgrade was complete. This was a revelation for me!
Then, on one Friday evening I spent a little time trying to help a translator working with a YAML file in Trados Studio. The file was ok, but was written in a way that the Supertext YAML filetype on the AppStore would not expose all the key/values required for translation. The Supertext app was needed because it was a bilingual YAML and the AppStore version supports bilingual YAML. The out of the box YAML in Trados Studio is monolingual. Notwithstanding that even as a monolingual file the same problem was there in the out of the box version too. I found a workaround… not sure if it helped as I didn’t hear back at the time of writing, but after experiencing Claude Code the week before I wondered if it could do something even more adventurous. So I spent a couple of hours that evening writing a specification for multilingual YAML, including referencing the full YAML specification so I could try to cover all eventualities. I also saved a local copy of my own plugin repo as an example of what a 2026 plugin framework looked like, and then after completing the ever expanding specification took a copy of the amazing Multilingual XML plugin written years ago by Patrick Hartnett (without AI!!) as this is a plugin I was heavily involved in wrt to the requirements and I wanted all these cool things in my Multilingual YAML. When I’d done all that I fired up a powershell terminal and pointed Claude Code to the folder on my laptop where all these files sat… and then went down to watch a film with my wife!
Mobile Phones!!
Now, I’d like to say that I watched the film in peace, but before I left my terminal I noticed a small message popup as Claude was coding giving me a link to continue the exercise on my phone if I wanted. If I wanted… of course I wanted… so I took my mobile down with me and every now and again (if my wife nipped out ;-)) I glanced at the phone, answered any questions that Claude asked along the way, and Claude got on with things while I “watched” the film.
Now this was a real revelation, as I could now do something else altogether, and simultaneously work on the building of a .NET application without having to open Visual Studio, or try to understand anything… I just let Claude get on with it and make decisions along the way when there are choices… and these are all choices that I can answer based on my own knowledge of how Trados Studio works best (in my opinion!) and what I think would be most useful to a translator trying to configure the filetype. I didn’t work for more than 5/10 minutes after the film was over… just long enough to test the first build on the plugin in Trados Studio 2026. It was far from feature complete, but it installed and could even handle a very basic YAML file!
As I started to drift off to sleep I was thinking about how I could now organise my Saturday… gardening and Claude all at the same time!!
I woke up, had some breakfast, fired up my laptop, got Claude Code started and headed out to do the lawn… phone in my backpocket set to vibrate! Every time I felt it go off I stopped, answered the questions, and carried on mowing. My lawn is a bit of an obstacle course as we have planted trees, embedded tires for planting into, set up rows of raspberries, added an arch etc. and with an electric mower still using a cable I have to think ahead, plan the route in advance and hope I don’t put a blade through the cable. Needless to say I did… happens once every three to four months… but despite this I finished the lawn, repaired the cable, and completed most of the functionality I needed for the plugin ready for testing in around an hour.
Now that felt like an achievement even though I wasn’t really doing the work. But easily within half a days work I had built a new filetype plugin for Trados Studio, and not a straightforward one either. I don’t think I could have done this without some knowledge of how Trados Studio worked to allow me to provide the instructions Claude Code needed, but considering I don’t know how to code this feels like a great example of how translators, project managers, localisation engineers, who have a great knowledge of how these types of tools work, can open the doors to being able to build anything they’ve always wished they could have but didn’t know how!
I know at least two translators already pushing the boundaries of what’s possible and taking full advantage of not only the APIs that Trados make available to to these types of things, but also building their own tools to allow them to work exactly as they always wished they could. Check them out if you’re interested… I think they are a great example of using the knowledge and experience they have gained over the years and embracing the new AI era to be able to grow with it:
These guys are an inspiration to other translators to see what’s possible… but maybe there are a lot more, and if there are I’d love to hear about them in the comments. Given the time I can certainly think of many things I could use this technology for just within the Tradosphere alone… never mind outside!
But back to the YAML filetype…
Testing the work
Over the course of the next week I spent my evenings testing the plugin. This turns out to be the place where human expertise is needed the most. Claude Code built it’s own unit tests and built up a significant library of several hundred tests it runs on the plugin with every change in the code to make sure nothing else was broken. If it was broken, it fixes the issue and runs the tests again, all without me being involved. But real testing that shows how things are displayed on the screen, how things are being extracted and appearing after translation, or saving the target files “currently” needs me. I created a bunch of test files trying to make sure that they incorporated all the possible ways in which the YAML specification supported its use.
What I also did, and I have not mentioned this yet, is ensure that the plugin is “born multilingual“. Trados Studio offers the user interface in English (United States), French (France), German (Germany), Spanish (Spain, International Sort), Italian (Italy), Japanese (Japan), Chinese (Simplified, China), Korean (Korea) and Russian (Russia). My YAML plugin has quite a bit of text in the UI as I also added small help guides for each feature accessible through a small dropdown below each one. I don’t need to tell anyone reading this how important it is to make sure that the translator receiving these strings has the full context to be able to translate them properly. But since Claude is building the plugin it certainly understands the context and so it seems logical that creating these translations while building the plugin is a no-brainer… born multilingual. All I have to do is check the UI in each language and try to make sure all the text fits in, is displayed without character corruption, has no English left in for other languages etc. Interestingly when I first asked Claude to do this the response was to ask me whether I wanted to use Language Weaver Pro (I have a small test MCP server using Language Weaver installed) and then post-edit in Trados! Since I don’t speak any of these languages, and I am a one man team building it, I declined and had to explain to Claude why I thought the LLM would do a better job for me… that got stored to memory and now every change in the resource strings is accompanied by an update in all supported languages.
To assist with all this testing I was saving screenshots into a folder that I could refer to when necessary for Claude to look at and better understand what I was explaining needed fixing. To begin with I was pretty convinced this is where I needed to be involved to provide the human touch. I said “to begin with” because that was before I discovered something else today (the next Saturday evening) while drafting this article and working on a another project in Claude Code related to a wordpress plugin I’ve been developing. This morning I spent some time setting up Claude Code with new found confidence to work on this WordPress plugin directly. I have been working on this for about 2-months now (it is a pretty ambitious project and I only have evenings and weekends) and given the complexity I have been excessively diligent with the documentation which includes things like:
- commercial business case
- technical design documents (one for the free core plugin and one for the paid pro version)
- reference guides to help me remember all the commands linked to working with WordPress, Docker, Powershell and Visual Studio Code
- build progress documents that I update after every nights work to make sure we pick up the next time I get to it with proper knowledge of what’s next
- full prints of the file/folder tree for each project
- etc.
Turns out all this diligence made it easy for Claude Code to pick up the project and take it over… even continuing to maintain this documentation as I had been maintaining it manually beforehand. What’s more… and this is where I wanted to get to… it suggested I move from the powershell terminal to Claude Code Desktop. So I took up the suggestion and was almost immediately prompted to allow a feature I wasn’t aware of called claude-in-chrome. This feature allows Claude to work in my local test setup of WordPress as a user by taking its own screenshots to see where everything is, and then clicking into the icons needed to operate the plugin as a user to test, taking more screenshots to review the result etc. So now I don’t even need to do that testing to the same extent I was before. In fact this evening, while writing this article, I completed more steps in this WordPress project than I could have achieved in a weeks worth of evenings! Now, I haven’t tested this with Trados Studio yet, although the popup help for claude-in-chrome suggested it could work in the browser or my applications… which makes me think it’s possible. Something to test on another day. I’ve attached a quick screenshot just to show this in action on my other project:
It’s staggering how quickly AI is helping developers to drive its own use forward at a rate we have never seen before. But I can’t emphasise enough how important it is to build the documentation and controls before starting a project that the AI can follow, even if it does suggest changes along the way, to avoid rewriting things that already worked, changing code that subsequently breaks something else etc. So for now, I think that for more complex projects your own expertise and controls are essential to be able to get the most from these projects.
Back to the YAML Filetype…
This article is probably more about what’s possible with AI these days as it is about the YAML plugin itself. But I should get back to that! YAML, of course, has a proper extended name, created with the best possible developer influence… YAML stands recursively for YAML Ain’t Markup Language (originally Yet Another Markup Language).  At its core, YAML is a human-readable data serialisation language. It’s designed to store and transmit structured data in a way that is easy for humans to read and write, and easy for computers to parse. So the key strengths (“Power”) of YAML are things like:
- unlike JSON or XML, YAML uses minimal syntax- relying on indentation (spaces) rather than curly braces ({}) or closing tags (</tag>).
- valid JSON is also valid YAML, meaning you can easily transition between the two formats.
- it natively supports scalars (strings, integers, floats, booleans), sequences (lists/arrays), and mappings (key-value pairs/dictionaries).
- it includes built-in support for comments (#), multi-line strings, and reusable anchors/aliases (& and *) to avoid duplicate data.
Check out the full YAML specification for all the details. Trados Studio has a built in monolingual YAML filetype, and the 2026 release of Trados Studio doesn’t have an app to support multilingual YAML at all. You can find the plugin in Trados Studio – Release 2026 itself through the AppStore feature, or by visiting the plugin on the RWS Appstore. I have added the help documentation there (and in even more detail in my L10N-X page for this app), but to give you some idea of the features this is what I have tried to support:
It works out the file for you
- Handles
.yamland.ymlfiles in Trados Studio 2026. - Works out on its own whether a file holds one language, a source and target pair, or several languages at once.
- When a file uses unhelpful labels like
col1andcol2, you just point at the right one once and it remembers for the whole project.
You get the file back exactly as it was
- Only your translations change. The developer’s comments, the layout, the spacing and the other languages in the file are all left untouched.
- An untranslated file comes back identical to the one you were given, so nothing you didn’t touch can break the developer’s work.
Files that hold several languages
- A single file with several languages opens as one Studio project.
- If the file already has some translations in it, one click pulls them in for review instead of retyping.
- When you’re finished, another writes every language back into one combined file, the way the developer expects it.
You decide what gets translated
- Files often mix real text with things that shouldn’t be translated, like code or settings. You can keep those out by clicking through your own file, with nothing technical to write.
- Placeholders such as
{name}and%sbecome tags you can move but not accidentally break. - HTML or other markup inside a value gets Studio’s proper tag protection, just like a normal job of that kind.
Comments and long text
- The developer’s comments can be left alone, translated, or turned into Studio comments to read beside your work.
- A long, multi-line value stays as one segment, or can be split line by line if that suits the text better.
Preview and languages
- While a file is open you can preview it as a simple table of the key (also searchable), your source and your translation.
- The plugin’s own interface is available in all nine languages Studio itself comes in.
Summary
For me this was as much about trying to build a more useful YAML filetype that could be easily used as it was about pretending to be a developer, thanks to what AI can now do. It also gets me thinking again about what AI means for our industry and for the wider world. Big topic I know, and I can see more and more people working in professions they loved getting very concerned about their future. This is understandable too, and I think… hope… that what we are seeing today is the result of some businesses seeing a way to make money with as little cost as possible and by employing as few people as possible. But this approach cannot last. The obvious reason being that if we replace everyone, who is left to pay for what is being provided?
But a more important one is that I’m not sure anyone actually knows how this is going to play out, including the fear-mongering, headline-grabbing types who tell you they do. What I can say is what I saw over the last fortnight.
Everything I built this month is based on things I didn’t build. Patrick’s Multilingual XML plugin from years ago, the YAML specification, and years of watching translators wrestle with filetype configurations and working out what actually helps them. Claude wrote every line of the code, but it had no idea what to write until I told it, and I could only tell it because of all that. Testing was the same story. Several hundred automated tests passed happily while things still didn’t look right on screen, and only somebody who knows what right looks like was ever going to catch that.
So the barrier for me was never understanding the problem, it was the years of skill I’d have needed to turn that understanding into something that runs. That’s the part that shifted. And I think the same shift is happening across our industry, because the scarce thing now isn’t producing the output, whether that’s lines of code or words on a page. It’s knowing what the thing needs to do, and being able to tell when it isn’t doing it. That’s something our industry has in abundance. My only worry is that a business which stops hiring the people who would have spent twenty years acquiring it will, in twenty years, have nobody left who can tell the AI anything useful at all.
Where that leaves the professions within our industry I genuinely don’t know. But I’d rather be one of the people finding out by building things than one of the people waiting to see what happens. And if you’re already out there doing it, please do say so in the comments. I think it would be interesting, and probably reassuring, for others to see. Just because you haven’t historically seen yourself as a technical person, and maybe even shied away from technical things in the past, doesn’t mean you can’t adapt. A technology that will do these things for you, based on your own knowledge pointing it in the right direction, also happens to be the most patient teacher you’ll ever have. And nobody else can see what you’re asking.

