It sounds like both the API and the website share a common language (PHP). In such a scenario I often find that the functionality used by the API can often be abstracted out into a less API specific object that other solutions (like the website) can also utilize.
This object would serve as a shared interface for the website and the API. Very little functionality then needs to live in the API code as it is simply operating as a translation layer between HTTP requests and the object.
It also saves the website from having to make network calls to an API and allows it to interact with the object more naturally.
If your API's functionality is relatively simple this runs the risk of being an over-architected approach so you'll need to consider if this is necessary and maintainable in your specific situation.
It seems there is no mainstream choice, so here is my suggestion :
Localisation files could be used more like semantic data than just text strings.
It seems reasonnable to expect identifiying a list , tagging a paragraph, a name or a part of a phrase being part of the localization team work.
So it could contain semantic (but no logical) html tags and use semantic span tags ( like <span id="seo-name"> ) in localization files.
Note : I here suggest span, wich is a valid html tag and so could be manipulated easily as a DOM element, but nothing stop you to use your own tags to parse.
Doing so you can in your view logic code, when extracting the text from the localization file, identify the seo-name, and adding the html link tags properly.
You may even, since some prior answer have made a security point about leting potentialy unknown people writting html code on your website, have a security parser wich check only limited safe tags (<p>, <ul>, <ol>, <li>, <span id="blabla">, ...) are present in localization files.
An exemple to illustrate :
If you have question, please ask our <a href="blabla" target="_blank" title="Our nice Customer Support + boilerplate SEO bullshit">Customer support</a> or write an email to <a href="mailto:XXX">Jane Doe </a> our specialist.
Could became in the file with thoses convention :
If you have question, please ask our <span id="customer-support">Customer support</span><span id ="customer-support-description">Our nice Customer Support + boilerplate SEO bullshit</span> or write an email to <span id="specialist-name">Jane Doe </span> our specialist.
Wich (I think) ins't really difficult to localize in french for (bad since closely-related) exemple by :
Si vous avez des question, n'hésitez pas à rencontrer notre <span id="customer-support">Service client</span><span id ="customer-support-description">Notre super service client + habituel blabla commercial</span> ou à contacter par email notre spécialiste <span id="specialist-name">Jane Doe </span>.
And a ugly controller pseudocode exemple :
$customerServiceParagraph = getLocalizedText("customerServiceContact",$lang);
$customerSupportDescription = getTextContentByElementIdThenDelete("customer-support-description"));
linkify($customerServiceParagraph,"customer-support",$customerSupportDescription,"blabla","_blank");
mailto_ify($customerServiceParagraph, "specialist-name","XXX" );
I'm far from being a localization expert but think the ordered or unordered list choice is a matter of cultural convention, and so is also a part of localization team work, even if I agree thoses tags are a legacy of dirty old styling/semantic tags collection of prior html versions.
Best Answer
Generally a web service should return raw data, and a consuming application that embeds the data in a web page would encode the data it embeds. That way other applications that might display the data in a Windows application or do some other processing on it don't have to deal with html.
If the purpose of a service is really to provide formatted text and uses html to represent the formatting, then it should be marked as such. Though you should consider how a non web-page consumer would use that data.