Refactor the code to support a requirement when the need arises.
Refactor the code to support a requirement when the need arises.
Better imo: Don't use strings but a proper datastructure/wrapper. Later, if you want to add i18n, then change `Wrapper("Hello, welcome to the future")` into `Wrapper("Hello, welcome to the future", "welcome-user")` and just look for all wrappers to find all places.
Benefits: it's easy to find the code with a simple ctrl+f from the English version of the site and you don't have any disadvantage except for having the English translation (or whatever primary language you choose) inside the code and the other translations in mapping somewhere else.
The thinking behind anti-YAGNI "future proofing" seem to be that it is cheaper to change something now than in the future. But I reject this premise. Inserting `Wrapper($string)` is exactly as much work now as in the future, but it will add additional overhead to all development going forward.
Perhaps the wrapper is even less work to introduce in the future, since you can add it with a simple search-replace, instead of inserting it manually every time you type a string.
You need user-messages? Then create user-messages and not strings. You don't need translations? Then don't create them.
Or in other words: make things a simple as you can but not simpler than they inherential are.
> Perhaps the wrapper is even less work to introduce in the future, since you can add it with a simple search-replace, instead of inserting it manually every time you type a string.
No you cannot, unless literally all strings in your program must be translated.
<h1>Hello world</h1>
Is less work and complexity than: <h1>{{ UserMessage("Hello world") }}</h1>
Introducing this abstraction before it is needed is a waste of resources and opportunity cost. Lets say you have the first solution, and someone decides "world" should be a link. Easy, you insert an <a>-tag. In the second example such a change would be much more complicated. You have suddenly made your work much more difficult for no benefit at all.Sure, if you discover at some point in the future that you actually need translations, then you have to work through all text and decide which strings need to be translatable. Yes, that is work, but you have done that anyway! There is no extra work. And every text which have been deleted between the abstraction was introduced and the translation became necessary, would have had an extra cost which is wasted anyway.
That project is 'done' when the interval between bug reports increases past some number where people decide it's done. But if you tell your boss "next month" then you're going to be proven wrong.
It sounds like you have had a bad experience?