Windows keeps obsolete strings forever to avoid breaking translations Changing text in Microsoft Windows requires freezing string updates well before code changes stop, often leading to strange wording that persists for years. These quirks aren't due to last-minute updates. Instead, it is all about the translations, according to veteran engineer Raymond Chen. "This deadline usually comes well …
The source of huge data wastage, those plain-text strings. Literally hundreds of kb could be wasted . You know, occasionally. And all this attitude gets is the decades of backwards-compatibility that's kept Windows as the default option.
Clearly these guys don't know what they're doing! They should tear everything up every couple of years so using Windows becomes a hobby (and identity) in itself!
And in a strange coincidence Microsoft has recently retired the Multilingual App Toolkit. I guess translations are yet another thing they've filed in the "this is too difficult for us to do now" bin.
In 2001, I wrote a mechanism that extracted all the strings from a VB app, and tokenised them. I also wrote a language manager. You could create a language, and then enter a translation for each token. If no token was found, the original text was displayed SO A CHANGE IN CODE DID NOT REQUIRE A TRANSLATION,
The tool that backported this into the app also used some AI* to identify common strings (E.g. "Yes", "No") and create a single entity so that one single translation could cover several strings.
All held in a SQL database that was loaded into memory and then interrogated on form load. With the added bonus that the customer could do the translating.
This was all done because the Dev Manager could not put into words how shite using DLLs for language resources that break if not kept in sync was.
This was for a financial services product used in Germany, Switzerland, France and Italy.
2001 - nearly a quarter of a century ago.
Presumably you made sure that a 20 character string in English that became a 50 character string in German (gotta love those compound words) didn't break your apps?
That's the difference between:
Internationalization (I18N): Making sure your code can handle translated strings without breaking screen layouts, etc.
and
Localization (L10N): Doing the translations into the desired languages (which may also require updating metadata about position of variable tokens within the strings)
I didn't do anything as fancy as that. But what I did do was to run a differ for all the (English) strings that our product held, comparing them to the last-translated release.
Then, along with all the other prep, I sent our translation team a list flagging the actual changes, making their life much easier than the teams doing the work on other languages who had to figure out what had changed for themselves.
( Yes, I tried to convince HQ to do this for other languages, but you know how not-invented-here gets perceived. And worst of all corporate sins, this was using an unknown hobby language named after a snake that I had picked up reading Dr. Dobbs. 1998 ).
Does sound like a bit of drama on the strings thingy, if it gets purged from release to release.
My impression of where Windows really used to bloat a system is in applying patches and them keeping them around forever in its installer directories. Having tried to emulate the Linux/Mac $HOME experience by putting Windows (7?) in a 50GB C: drive and installing everything else in D: I watched in horror as it gradually bloated itself into running out of space. I don't know if they've fully fixed that yet, been off Windows for years now. No, having to run special programs and having to manually follow internet guidance doesn't count as MS having its act together here.
Every software company I've worked at does this differently and, invariably, badly. One product i worked on was localised into about 14 languages. The reality was that it was only ever thoroughly tested on English. In one particular release, we missed a French string. If a French user accessed a particular menu, instant crash! Merde!
And the entire Chinese open-source technology business, building cheap phones, smart watches, toys, whatever.
This is all in Hanzi. It enables manufacturers with limited technical understanding to enter production, and developers with technical skill to create variants.
Worked on a product which was localised into German, amongst other languages. We had to make the UI about twice as wide as English to accommodate the translated German compound words. The worst language was Polish which had to agree on gender and case. If our Polish translation was good, we knew we were in good shape for the other languages.
We had a product which we wished to sell into Germany, so being bright (this was the 1980s) we contacted a couple of German companies with products in our area and asked for their sales literature in German, got the sharp reply “we have none, it’s all in English”, so we didn’t do a German localised version…
One could always use Professor Farnsworth's Universal Translator.
Worked on a product which has localised into a number of different languages including Arabic ie Right To Left (RTL). Every few years, our sales people would say: "If only it fully supported Arabic, we could sell thousands of these and make the company millions!". We'd then sink about 6 months of dev time fixing all the RTL issues. Number of extra sales: zero. Until a few years later when the cycle would repeat.
Your parent quite literally gave an example.
Arabic as a whole is largely written R2L You note that numbers are written L2R in Arabic.
Mr Harston notes that quoting foreign phrases within Arabic is written according to the preferred direction of the quoted language. English is a habitual L2R language, so english quotes will be L2R.
There are actually very good, well researched and tested reasons why keyboards are the way they are...the history is long and very boring so I won't link the wikipedia article, also those that are curious about QWERTY probably already know about QWERTY. A keyboard layout in alphabetical order is actually awful, I know, I've tried...you end up lopsided while you type.
When home users got the Minitel in France in 1983-84, some models had an "abcde" keyboard.
Nobody complained then, since they were typing with one digit anyway, unless they were secretaries accustomed to the standard "azerty" layout.
The next iterations all used the "standard" layout.
With the latest versions of Win11, MS introduced the new AFNOR-designed layout as the "standard", relegating the current layout to "legacy" status.
So anyone not paying attention will have a surprise entering passwords the first time...
Of course, nobody is selling that new standard keyboard as far as I can say, and the manufacturers I am in contact with are not aware of its existence.
(and I didn't find any either on the Microsoft store)
I love that guy however as a Microsoft employee he insists not seeing the elephant in the room. It is closed source model Vs open source/community. KDE project for example is gigantic and old. They don't have to cope with this problem.
Also, using their model Apple does have an excellent, native like Turkish translation while Windows one reads like a bad sci fi movie script.
When I wrote a VB application decades ago, the app itself only held tokens. These tokens were looked up in a file and replaced by strings which could be in whatever language (it would look for a file named after the system language, falling back to English if it didn't exist).
If you're familiar with RISC OS MessageTrans, it's basically an implementation of that.
Hey Microsoft, can I have $10bn for my solution please?
Use a constant in the code, e.g. STRING_FILESYSTEM_ERROR_43287.
When you want to print that message, you use that constant.
Have a bunch of separate files that define that constant for each language and/or can change that "constant" on the fly if the user is switching languages. Like a variable.
At no point then do you have to reference the original English string ever. You just reference the constant.
If you need to update the English, or the Guatamalan, or whatever translation... you can do that at any time without having to keep reference to what it used to say, and neither do you have to lock down the translation in perpetuity in order to keep track of it.
Hell... you could keep the translated files in something like a .po file....
(Seriously: What a dumbass way to handle translations).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
