"Imagine the pain they will go through when they next need to internationalize the application into multiple languages."
Actually I did just that late last year. It took one day to write a parser to find string constants in source code and put them into a CSV file, then another day to write and test a mutator script to replace the text with i18n constructs and generate the resource file. Meanwhile, we sent out the csv file to multiple translators to translate into 8 different languages. Total development and implementation time: 3 days. Getting good translations made, on the other hand, took weeks and required multiple verifications and lots of pain.
I'll take a possible future 3 days work any day if it avoids daily pain from implementing annoying localization constructs that we may never actually need.
If it ain't broke, don't fix it. It sounds like for you merging of simultaneous changes to the same file by multiple developers due to one person coding features while the other writes error messages wasn't a pain you needed to address so it made sense to delay the work to a future date.
I think you've mixed up the stories... The merging issue was a fictional story. With us, we simply didn't bother writing for internationalization to begin with (following the principle of YAGNI). And it turns out that when the unlikely DID occur (we actually needed it after all), the pain was minimal after a little creative thinking.
Merging often is something I like, but not for the reasons laid out in the article. I like it because it lowers the chances of a freak ugly merge, and more importantly because smaller merges means smaller code reviews (my eyes-glaze-over point is about 200 lines or so). But I wouldn't use it simply as a way to make painful merges more frequent yet less intense. Recurring painful merges are generally a sign that something could be structured better. That's where strategy separates the good teams from the mediocre.
Yes, I get that Jane and Joan are fictional and that your story is real. Perhaps I didn't state things clearly so I'll try again:
If you'll allow me to propose a hypothetical: let's say you did have recurring painful merges because (borrowing from the fictional story) someone was continually adding new features while someone else was continually tweaking error messages such that there were many conflicts which needed resolving upon every code check-in. You likely would have put the error messages into resource files much sooner and avoided these recurring painful merges. But because you didn't have this hypothetical situation (it ain't broke, thus you didn't fix it) it made sense to push the pain of localization off to when it was actually needed.
Actually I did just that late last year. It took one day to write a parser to find string constants in source code and put them into a CSV file, then another day to write and test a mutator script to replace the text with i18n constructs and generate the resource file. Meanwhile, we sent out the csv file to multiple translators to translate into 8 different languages. Total development and implementation time: 3 days. Getting good translations made, on the other hand, took weeks and required multiple verifications and lots of pain.
I'll take a possible future 3 days work any day if it avoids daily pain from implementing annoying localization constructs that we may never actually need.