Fixing that small internationalization gaffe
The engineers resolved the internationalization problem. Sort of.
They’ve modified the logic so that it no longer depends on the hardcoded presence of “&Tools” to pull the resources in correctly from two separate DLLs. However, it still looks for the literal “&Edit” in each DLL. If it doesn’t find it, the submenu items do not show up. I know, because I broke it again with a random pseudo-translation pass that rendered “&Edit” as “&ßéüdßéüt” in one resource file and “&ßéüñdßéüñt” in the other.
“Well, what do you expect?” asked the developer, when I explained this to him. “Get your pseudo-act together and you won’t find problems like this.”
I granted him that it was very unlikely that “&Edit” would be translated differently in two places – well, it could happen, but it should not happen – but that was not the point. It’s just not good programming practice to depend on string literals like that, whether localization engineering is a concern or not. “Why don’t you make the dependency on the string ID instead? Localization will never go near that.”
“Submit a ticket on it and we’ll see for next time,” he replied. “I’ve got other dragons to slay right now.”
So, I filed the request and the enhancement is in the great cosmic wash of the engineering team’s Issue Review system.