Is it a best practice to always store strings in ASP .resx resources files, even when the application is not localized according to the user culture ? (Web pages will be displayed in french.)
Is there reasons for using resources other than provide pages in different languages easily ?

  • In favour of resources, something "smells wrong" or "seems ugly" about writing code that mix HTML, ASP/Razor and hard-coded strings :

    @Html.LabelFor(Model.FirstName, "Votre prénom :");
    <input type="submit" value="Modifier votre profil" />
    <div class="error">Une erreur est survenue</div>

    Or worse, mixing .NET/C# code and hard-coded strings :

    [Display(Name = "Le salaire actuel de l'employé")]
    public int Salary { get; set; }
  • In favour of hard-coded strings, using resources when they aren't needed is consequent extra-work for the developer and (seems to) violate YAGNI.

  • 1
    I don't know about best practice, but in my opinion, it's not a whole lot of extra work to keep a resource file up-to-date. Once you've done a lot of the initial work, you can actually reuse a lot of strings. And, if you ever do need localized strings, you'll be really happy you did this. Seriously, I cannot stress how happy you'd be. – Ivo Coumans Dec 10 '14 at 14:39
  • I would go with a yes, cause you often tend to use some words or sentences multiple times. That works kinda great with .resx files :) – Knerd Dec 10 '14 at 15:24

The nice thing about YAGNI is that it can be quantified. There are three metrics too look at:

  • The time saved by applying YAGNI and not implementing something up-front.
  • The probability that the application will have to be rewritten
  • The time needed for rewriting the application a couple of years in the future.

When time saved > time needed for rewriting × probability of rewrite, then it is advantageous to not invest in a more flexible architecture right now. YAGNI can be understood as a heuristic that says “the probability of a rewrite is near zero, so it can usually be ignored”.

But here we have a case where the time saved is very small compared to the time needed for a rewrite of all your templates, and the probability of a rewrite is probably not nil – what are the odds that the website would want to offer navigation in English some time during the next five years? That sounds like a reasonable requirement for most sites.

So instead of having to rewrite the application later, you may want to do it right the first time.

Of course, using localization has advantages beyond supporting multiple languages, for example proper formatting of numbers and quotation marks. Also, not putting text into templates helps separating implementation from design from content. Ideally, a non-programmer would be able to change the text of a button, and would not have to search through a template file. Such considerations further skew the advantage towards using a proper design even when it feels like overkill.

I recently wrote a small website (using a different technology stack) and went through these considerations. In the end, I found that in my case the probability of having to support additional languages was negligible, so I didn't go for internationalization. However, I took on some technical debt through this decision because my template files are admittedly a bit of a mess. Using localization files would not have completely solved this, but would have helped keeping different concerns separate. I estimate that my decision to skimp on localization files was not worth it, because I'll have to rewrite the templates anyway.

  • +1 for answering, explaining YAGNI, and using personal experience. – Clément Dec 15 '14 at 8:50

There is no definite answer. Personally I'm strongly against internationalizing when you don't need it. I have done tons of corporate web sites and I can say for sure that doing internationalization consumes more time than you imagine at first. Event when using more advanced and less tedious methods than resource file provides.

Keep in mind, that you can have some kind of text's in database, deep in your backend, JS validation messages, etc. Not everything is translatable with resources. And don't forget cases when user browser has different culture than your server (i.e. 0,3 is validates in browser, but fails in backend).

Having text hardcoded in your view models and using fixed culture is real joy and relaxation :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.