4 ms·

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 s

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.
    - goto11 4y ago
      Lets say I write a HTML page. <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.
      - valenterry 4y ago
        Oh, if you write HTML then you are already using semantic wrappers. I.e. you already used <h1> which clearly indicates your intend.
sonthonax 4y ago
Agreed, lots of things never need to be internationalised. Pretty much everything in institutional finance will never need it.
deleted 4y ago
[deleted]
hinkley 4y ago
Have you done that refactor? There is no timeline you can do once people are just injecting static text everywhere in the app. 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.
- bazoom42 4y ago
  Are you asking if I have ever added internationalization/translation to an app which initially didnt have it? Yes I have done that. It sounds like you have had a bad experience?

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.
  - goto11 4y ago
    Lets say I write a HTML page. <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.
    - valenterry 4y ago
      Oh, if you write HTML then you are already using semantic wrappers. I.e. you already used <h1> which clearly indicates your intend.

sonthonax 4y ago

Agreed, lots of things never need to be internationalised. Pretty much everything in institutional finance will never need it.

deleted 4y ago

[deleted]

hinkley 4y ago

Have you done that refactor? There is no timeline you can do once people are just injecting static text everywhere in the app. 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.

bazoom42 4y ago
Are you asking if I have ever added internationalization/translation to an app which initially didnt have it? Yes I have done that. It sounds like you have had a bad experience?