Today was one of these days where I wonder why the hell I am a developer when there are so many great jobs out there : Matrasses tester, pizza eater, Aussie snorkeler,...
I was debugging a couple of apparently unrelated small bugs which altogether led me to discover that I was really not dealing correctly with carriage returns and line feeds in the multiline translatable text items.
Yesterday, I already spent much time trying to solve a stupid little usability problem related to multiline texts: When <enter> means 'OK', do people know that <ctrl+enter> is used to enter a line feed ? I eventually came out with this visual clue (enlarge
) appearing when a multiline text item is selected:
Today, I noticed that this warning is ALWAYS on when the message table is opened (The message table looks like the string table, just different!). It appeared that messages from that table always end in CRLF, which made appTranslator
believe they contain at least 2 lines of text! Since I don't want people to stupidly have to type <ctrl+enter> at the end of each message, I decided to strip these final CRLFs when importing the tables and re-append them when building the target file.
I must also say that when you click OK in the translation pad, appTranslator converts all CRLFs back to simple LFs (line feeds), because multiline strings usually contain single LFs. And since the rich edit control in the translation pad happily and silently converts single LFs to CRLFs, someone must reverse the conversion some day...
Convert alls CRLFs to LFs ? This ain't no true anymore, since the message compiler emits CRLFs only. Hence, how do I know when I get this string back from the rich edit with CRLFs into it if the app that is going to use these strings (your app!) expects single LFs, single CRs or CRLFs ?
So I wrote another 50+ lines of codes to compare the line breaks of the translated strings with the one in the source string. And make sure the translated string uses the same as the ones in the source string.
And each time an appTranslator
user presses OK, a Pentium-class processor will spend a couple of µ-secondes checking if these conversions must be performed...Are you still with me ?
Rocket science, isn't it! All this because some day, probably at a time when the Universe had not planned to turn a bunch of atoms into you and I yet, someone decided that a line feed would consist in 2 characters (CR and LF). And later, another someone figured it would be easier to process the files if all CRLF pairs were first converted to a single LF, but keep them as CRLFs in the file so that the first someone doesn't notice. So, now, 40+ years later, I have to spend hours figuring how to deal with that mess.Save the planet!
I'm sure that the power consumption required by millions of computers worldwide to perform CRLFs conversions all day long easily adds up to a nuclear power plant. Here's a great slogan for all the ecologist geeks out there: "Save the planet: Stop converting CRLFs !"