Hard code and refactor when you need it. Time is money, yadda-yadda, is it worth the time/money to have the unused feature?

Also, it’s not hard to do later as much as it is tedious. Pawn that task off to a junior developer when the need arises.

Finally, when the time comes, some automated tools may get you most of the way there. Such as Eclipse’s string externalizer.

Making applications multi-language does take some additional development effort. You can either invest that effort right from the start, every day a bit. Or you can invest that effort afterwards, when you have written >100K lines-of-code. Fact is, the sum of the needed efforts in both cases is not so very different as you might think.

The first approach actually disguises the needed effort which make some people believe the second approach is more costly, but IMHO that’s a misconception. The second approach actually shows you the real costs and makes them much more transparent. And that is what the YAGNI principle is about: saving that hidden costs at the time you are not ready to invest it.

That said, providing applications for multi-language support right from the start might be the right strategic decision for lot of software products, especially when there is a good chance to sell those applications to a wider audience. But one should not believe that such a decision comes totally for free.

YAGNI is often in opposition to other established principles and/or best practices. Other examples include several of the SOLID principles, which are largely about structuring your code to make certain kinds of change easier in future. But what if you don’t ever need to make those changes? Then the extra work involved in, say inverting the dependencies between two different parts of your application, and the extra complexity introduced by the unnecessary abstractions that such an inversion requires, is wasted.

YAGNI doesn’t mean we should never do such things. It does mean we should stop to think before doing it and make a serious assessment of how much effort we’re about to put in, how likely it is to pay off, and how much easier it is now than later.

In your example of externalizing strings, the amount of effort is small, but it is also not much harder to do it later, as Doc Brown has suggested. And you’re the only one who knows how likely it is that you will need i18n support in the future.

Personally, I’m inclined to leave this particular task until it is necessary, but my experience is largely in building internal apps for SMEs that rarely need the facility, and I work with tools that have support for automatically refactoring to an external string resource. Your market and tools may be different, which might result in a different decision.

With just a few exceptions, code, data and configuration should be separated. Hard-coding is generally considered a bad practice. You should put UI text into separate file just so you know where to find it, not because you might need i18n. This will not take much longer than hard-coding, but maintainability will be better.

Also with external resource file you will be able to change text without rebuilding/redeploying an app. This may be the case for web apps, for example.

So, this is not breaking YAGNI, but just following other principles/practices.