2 ms·

Sounds a lot like translating a web app after it was released. In a company I was working on, we made a commitment to call out strings without gettext as a bug,

by aclsid 10y ago

Sounds a lot like translating a web app after it was released. In a company I was working on, we made a commitment to call out strings without gettext as a bug, regardless if it was really was going to be used for a single country/language. It really takes no effort to do it the first time, but adding that stuff later on is major bs.

hinkley 10y ago
Oh, we did that too (and somehow I ended up being in charge of both. Whoopie!) But I decided to cut myself off at two sob stories :) Security, concurrency, and localization are three things you can't just tack on later. Anyone 'test infected' would add automated testing to that list too. They all involve a long game of whack-a-mole and they're IME bad for morale and productivity.
hinkley 10y ago
I've found that you can grease the wheels a lot by explaining to management that using the localization features of the language means that stories don't get held up by arguments about terminology. That's been sufficient to get them to agree to localization on three products, two of which almost immediately got surprise customers (or new owners) for our "always english only" application that suddenly wanted it in 3 languages in 3 months. :/ But for now, if I use this technique in the code, and you business guys want to start calling files 'assets', or clients 'customers' (or vice versa), then you guys can go fight it out in a room and just tell me what you want afterward.
Pxtl 10y ago
The reason it's hard to bolt-on after the fact is that languages conflate the concept of "string" and "user-facing text". If "user-facing text" had a different type or method or whatever, it would be trivial to find all references in your codebase and consolidate them into gettext stuff. But instead, every inline dynamic sql, every dictionary key, every http parsing looks like user-facing text.

by aclsid 10y ago

hinkley 10y ago

Oh, we did that too (and somehow I ended up being in charge of both. Whoopie!) But I decided to cut myself off at two sob stories :) Security, concurrency, and localization are three things you can't just tack on later. Anyone 'test infected' would add automated testing to that list too. They all involve a long game of whack-a-mole and they're IME bad for morale and productivity.

hinkley 10y ago

I've found that you can grease the wheels a lot by explaining to management that using the localization features of the language means that stories don't get held up by arguments about terminology. That's been sufficient to get them to agree to localization on three products, two of which almost immediately got surprise customers (or new owners) for our "always english only" application that suddenly wanted it in 3 languages in 3 months. :/ But for now, if I use this technique in the code, and you business guys want to start calling files 'assets', or clients 'customers' (or vice versa), then you guys can go fight it out in a room and just tell me what you want afterward.

Pxtl 10y ago

The reason it's hard to bolt-on after the fact is that languages conflate the concept of "string" and "user-facing text". If "user-facing text" had a different type or method or whatever, it would be trivial to find all references in your codebase and consolidate them into gettext stuff. But instead, every inline dynamic sql, every dictionary key, every http parsing looks like user-facing text.