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 prnom :);...<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.
Should I use ASP .resx resources if the website is available in a single language?
programming practices;asp.net mvc;localization
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 rewrittenThe 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.