Perhaps a weird reason but it is a reason
It's not a reason, it makes no logical sense to convert an entire dedicate web application to something that is not. Even if I *was*, I think the fact there are HTML in language strings would be the least of my worries, since all the other code would need to be ported and would most likely included different language stings. I know 100% that this application will always be a web application.
Are you going to let your users edit the language code? Will you filter the language codes to prevent XSS? Are you prepared to include HTML in all of your translations? What if (instead of porting) you sometime in the future decide to use XXXHTML instead of XHTML are you prepared to modify your language tables AND the HTML templates?
The language strings would be edited by translators and released by us as language packs, HTML is allowed in them regardless, however they will of course be reviewed by us, so any malicious content would be found (these would be translators brought in to translate the application, not edited by your average Joe through the application, just to make things clear).
HTML within the language strings, would not be much (I'm not talking about full blow tables or complex HTML), it would just be small amounts such as in the examples given.
Personally I keep HTML out of anything but HTML template files -- which are alternative snyax PHP scripts if anything.
As do I, however these language strings are causing an issue with that. How would you get around this?