Counter-point: Don't hard-code all your UI strings, thinking you'll never need to be multi-lingual, because then you are setting yourself up for a massive re-work if that need arises. And even if you stay at one language, you really don't want to have to re-build and re-deploy an app just to change the words on a page or a label.
Take the time to extract UI strings from the code, even if only building a single language. It isn't that complex, and will certainly pay itself back if you get any traction at all.
Are you suggesting that we build a multilingual architecture right from the start of the startup? Without testing the hypothesis, without testing the market and demand?
The only thing we're talking about here is the difference between <p>Hard-coded string</p> and <p>${strings.notHardCoded}</p>
That is really just some file organization and some code syntax, not a major architectural difference. And it gets you a long way towards going multi-lingual when you need it, without much effort at all.
You have to create keys, copy the text into a file, and when editing the text, you need to update that file instead of the code. When removing the interface, don’t forget to delete the keys from the file. When moving the interface, you need to reorder the keys in the file. When changing the meaning of the text, you need to change the key name. The benefit of these actions is almost zero if the startup has no users.
Counter-point: Don't hard-code all your UI strings, thinking you'll never need to be multi-lingual, because then you are setting yourself up for a massive re-work if that need arises. And even if you stay at one language, you really don't want to have to re-build and re-deploy an app just to change the words on a page or a label.
Take the time to extract UI strings from the code, even if only building a single language. It isn't that complex, and will certainly pay itself back if you get any traction at all.
Are you suggesting that we build a multilingual architecture right from the start of the startup? Without testing the hypothesis, without testing the market and demand?
The only thing we're talking about here is the difference between <p>Hard-coded string</p> and <p>${strings.notHardCoded}</p>
That is really just some file organization and some code syntax, not a major architectural difference. And it gets you a long way towards going multi-lingual when you need it, without much effort at all.
You have to create keys, copy the text into a file, and when editing the text, you need to update that file instead of the code. When removing the interface, don’t forget to delete the keys from the file. When moving the interface, you need to reorder the keys in the file. When changing the meaning of the text, you need to change the key name. The benefit of these actions is almost zero if the startup has no users.