6 ms·

* Having all user-facing strings in a common place. It doesn't take much effort, but makes it so much easier in the future when you suddenly either need intern

* Having all user-facing strings in a common place. It doesn't take much effort, but makes it so much easier in the future when you suddenly either need internationalization/translation (both tech side making the switch, but also gathering all the strings to send to some translator), or it's requested that these be managed by a cms of some sort instead of hardcoded all over the place.

robertlagrant 4y ago
True, although at least on mobile I think this is a button press in the IDE. Maybe Javascript/non-mobile native apps have it harder.
- taink 4y ago
  Yes, I can think of Android Studio which pushes you into using Android's string resources[0], which have out-of-the-box support for i18n and are essentially big XML files. [0]: https://developer.android.com/guide/topics/resources/string-resource https://developer.android.com/guide/topics/resources/string-...
  - hinkley 4y ago
    I haven't worked in Android, but a quick perusal at least passes my giggle test, which frankly too many languages do not. This is essentially a refinement of the i18n support that has been in Java for ages. I probably would not have stuck with Java as long as I did if their localization support wasn't as good as it was (not to say it's perfect, because it's a bit clunky). Google has made a few of the examples into a more concrete requirement, which is nice.
iLoveOncall 4y ago
I haven't worked with a lot of i18n systems, but on the contrary I have found them to be a huge amount of work. I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plurals and others. I just want to write my damn text. I'd rather spend days doing the mind-numbing work when needed rather than slow down my development process and remove all enjoyment from it ad vitam aeternam because of i18n-ing on the fly.
- BlargMcLarg 4y ago
  On the other side we have the individuals inheriting such codebases and being told to add multilingualism when a bunch of other soft dependencies and assumptions exist which make this entire thing a disaster to implement. It is fairly small and trivial to add so please, if you foresee an event where systems have to support multiple languages and odds are you won't work on it yourself, prepare the damn codebase for it.
- matsemann 4y ago
  You don't need to bake in a complete i18n solution, though. Just create a simple map of keys->strings, and then a function ala getStringForKey(key, language) { return map[key] and then whenever you actually need it, just expand on it. But at least you then have all strings in one place, and a common way of accessing them. (And easy lookup of all places using these strings)
  - sonthonax 4y ago
    Agreed. I don’t really know what problem these i18n tools solve that this doesn’t.
    - matsemann 4y ago
      But if you end up in a situation where i18n tools are needed, this function can be the single entry point anyways, abstracting most of it away.
  - iLoveOncall 4y ago
    Your function doesn't solve any of the issues I mentioned, you still need to switch to another file, still need to think of a sufficiently explicit key, still need to handle plurals and masculine / feminine variations, etc.
    - matsemann 4y ago
      YAGNI ;) You can skip all those things the first time. You don't need to have a separate file or anything. Just have a stupid function returning its input or whatever. The important part is having an entry-point, and an easy way to find all relevant uses in the future. You could then later, when i18n is needed, write a script finding those usages and automatically extract them. That's what I've done once before. And it was a thousand times easier than the time before where we had to hunt through all of frontend, backend, cms etc. to find stuff.
bazoom42 4y ago
Sure, but what if you never need to internationalize? Introducing a level of indirection have a cost. This is exactly why YAGNI applies. Refactor the code to support a requirement when the need arises.
- valenterry 4y ago
  Exactly. 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.
  - goto11 4y ago
    This is still not YAGNI enough for me. Why introduce a wrapper you don't need? 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.
    - valenterry 4y ago
      I don't think so. That's just a semantic description of what you are doing. Call it `UserMessage("....")` or whatever. If you go without that and have simply plaintext for any kind of thing, you might at some point mix up passwords with user messages and stuff like that. Has nothing to do with future-proofing. 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.
malandrew 4y ago
I would go further with your idea. You should have all I/O separated and in on place. UI is just a special case of I/O for apps. In services you also want to keep all RPC handlers in on place (or any interface with which others interact with your binary). You also want to keep any interfaces with which you make IPC calls each separate and in one place as well. I use IPC (inter process communication) as this includes service clients, database clients, disk access, peripheral access, etc as well.
jaza 4y ago
I once worked on a large app that had always tried to support translation, but that had never actually been used by clients (after more than a decade running in production) in a language other than English. Well, what do you know, after all those years, finally a big client signed on, and this client needed the whole UI not in English. Trouble was, in practice there were gaps in the translation support all over the place, and so several rounds of patching those gaps and performing manual testing were needed, which took a lot of time and manpower. So, was it worth half-maintaining the translation support for so many years? I guess it would have been even more work had it needed to be added from scratch; but it was still a lot of work cleaning it up. Ironically, the client in question then cancelled on us, shortly before going live, and after we'd finished all that work. Although another non-English client did go live with us the year after that, so it wasn't wasted effort in the end.
- creeble 4y ago
  Not too ironic I think, more common than not. I wish I had a box of nickels for every feature that cost $100k+ to implement that ended up being a dead end (i.e., sales benefit never materialized) or, even more commonly, the benefit materialized and was less than $100k and resulted in a feature that required continued maintenance and ongoing support cost forever.
- bcrosby95 4y ago
  I think this is one of the biggest problems with violating YAGNI. They're effectively dead code paths that are never truly being executed, and developers might assume they aren't full of bugs. But they oftentimes are.
- hinkley 4y ago
  There's hard coding strings, and then there's hard-coding sentence fragments. If you hard code strings, you can't translate at all. If you hard-code sentence structure ("There are " + n + " copies of this book in stock") then you're going to sound like Yoda in a number of languages. Adjectives are a particularly bad sticking point. Is it a large red book (English), a large book that is red (French), or a book that is large and red? But Verb-Object-Noun order also vary just within first world nations, so even the lame classist/racist/nationalistic excuse of "We don't need their money anyway" doesn't really fly. One of your competitors will be very happy to take Japan's money.

robertlagrant 4y ago

True, although at least on mobile I think this is a button press in the IDE. Maybe Javascript/non-mobile native apps have it harder.

taink 4y ago
Yes, I can think of Android Studio which pushes you into using Android's string resources[0], which have out-of-the-box support for i18n and are essentially big XML files. [0]: https://developer.android.com/guide/topics/resources/string-resource https://developer.android.com/guide/topics/resources/string-...
- hinkley 4y ago
  I haven't worked in Android, but a quick perusal at least passes my giggle test, which frankly too many languages do not. This is essentially a refinement of the i18n support that has been in Java for ages. I probably would not have stuck with Java as long as I did if their localization support wasn't as good as it was (not to say it's perfect, because it's a bit clunky). Google has made a few of the examples into a more concrete requirement, which is nice.

iLoveOncall 4y ago

I haven't worked with a lot of i18n systems, but on the contrary I have found them to be a huge amount of work. I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plurals and others. I just want to write my damn text. I'd rather spend days doing the mind-numbing work when needed rather than slow down my development process and remove all enjoyment from it ad vitam aeternam because of i18n-ing on the fly.

BlargMcLarg 4y ago
On the other side we have the individuals inheriting such codebases and being told to add multilingualism when a bunch of other soft dependencies and assumptions exist which make this entire thing a disaster to implement. It is fairly small and trivial to add so please, if you foresee an event where systems have to support multiple languages and odds are you won't work on it yourself, prepare the damn codebase for it.
matsemann 4y ago
You don't need to bake in a complete i18n solution, though. Just create a simple map of keys->strings, and then a function ala getStringForKey(key, language) { return map[key] and then whenever you actually need it, just expand on it. But at least you then have all strings in one place, and a common way of accessing them. (And easy lookup of all places using these strings)
- sonthonax 4y ago
  Agreed. I don’t really know what problem these i18n tools solve that this doesn’t.
  - matsemann 4y ago
    But if you end up in a situation where i18n tools are needed, this function can be the single entry point anyways, abstracting most of it away.
- iLoveOncall 4y ago
  Your function doesn't solve any of the issues I mentioned, you still need to switch to another file, still need to think of a sufficiently explicit key, still need to handle plurals and masculine / feminine variations, etc.
  - matsemann 4y ago
    YAGNI ;) You can skip all those things the first time. You don't need to have a separate file or anything. Just have a stupid function returning its input or whatever. The important part is having an entry-point, and an easy way to find all relevant uses in the future. You could then later, when i18n is needed, write a script finding those usages and automatically extract them. That's what I've done once before. And it was a thousand times easier than the time before where we had to hunt through all of frontend, backend, cms etc. to find stuff.

bazoom42 4y ago

Sure, but what if you never need to internationalize? Introducing a level of indirection have a cost. This is exactly why YAGNI applies. Refactor the code to support a requirement when the need arises.

valenterry 4y ago
Exactly. 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.
- goto11 4y ago
  This is still not YAGNI enough for me. Why introduce a wrapper you don't need? 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.
  - valenterry 4y ago
    I don't think so. That's just a semantic description of what you are doing. Call it `UserMessage("....")` or whatever. If you go without that and have simply plaintext for any kind of thing, you might at some point mix up passwords with user messages and stuff like that. Has nothing to do with future-proofing. 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.

malandrew 4y ago

I would go further with your idea. You should have all I/O separated and in on place. UI is just a special case of I/O for apps. In services you also want to keep all RPC handlers in on place (or any interface with which others interact with your binary). You also want to keep any interfaces with which you make IPC calls each separate and in one place as well. I use IPC (inter process communication) as this includes service clients, database clients, disk access, peripheral access, etc as well.

jaza 4y ago

I once worked on a large app that had always tried to support translation, but that had never actually been used by clients (after more than a decade running in production) in a language other than English. Well, what do you know, after all those years, finally a big client signed on, and this client needed the whole UI not in English. Trouble was, in practice there were gaps in the translation support all over the place, and so several rounds of patching those gaps and performing manual testing were needed, which took a lot of time and manpower. So, was it worth half-maintaining the translation support for so many years? I guess it would have been even more work had it needed to be added from scratch; but it was still a lot of work cleaning it up. Ironically, the client in question then cancelled on us, shortly before going live, and after we'd finished all that work. Although another non-English client did go live with us the year after that, so it wasn't wasted effort in the end.

creeble 4y ago
Not too ironic I think, more common than not. I wish I had a box of nickels for every feature that cost $100k+ to implement that ended up being a dead end (i.e., sales benefit never materialized) or, even more commonly, the benefit materialized and was less than $100k and resulted in a feature that required continued maintenance and ongoing support cost forever.
bcrosby95 4y ago
I think this is one of the biggest problems with violating YAGNI. They're effectively dead code paths that are never truly being executed, and developers might assume they aren't full of bugs. But they oftentimes are.
hinkley 4y ago
There's hard coding strings, and then there's hard-coding sentence fragments. If you hard code strings, you can't translate at all. If you hard-code sentence structure ("There are " + n + " copies of this book in stock") then you're going to sound like Yoda in a number of languages. Adjectives are a particularly bad sticking point. Is it a large red book (English), a large book that is red (French), or a book that is large and red? But Verb-Object-Noun order also vary just within first world nations, so even the lame classist/racist/nationalistic excuse of "We don't need their money anyway" doesn't really fly. One of your competitors will be very happy to take Japan's money.