Dovrebbe essere evitato l'inserimento di tag html in file di localizzazione?

Sembra che non ci sia una scelta mainstream, quindi ecco il mio suggerimento:

I file di localizzazione potrebbero essere utilizzati più come dati semantici che solo stringhe di testo. Sembra ragionevole aspettarsi di identificare un elenco, taggare un paragrafo, un nome o una parte di una frase che fa parte del lavoro del team di localizzazione. Quindi potrebbe contenere tag html semantici (ma non logici) e utilizzare tag di span semantica (come <span id="seo-name"> ) nei file di localizzazione. Nota: qui suggerisco span, che è un tag html valido e quindi potrebbe essere facilmente manipolato come elemento DOM, ma niente ti impedisce di usare i tuoi tag per analizzare.

Facendo così puoi nel tuo codice logico di visualizzazione, quando estrai il testo dal file di localizzazione, identifica il nome seo e aggiungi correttamente i tag link html.

Potresti anche, dal momento che alcune risposte precedenti hanno fatto un punto di sicurezza sulla possibilità di identificare persone potenzialmente sconosciute che scrivono codice html sul tuo sito web, avere un parser di sicurezza che controlla solo tag sicuri limitati ( <p>, <ul>, <ol>, <li>, <span id="blabla">, ... ) presenti nei file di localizzazione.

Un esempio per illustrare:

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.

Potrebbe diventare nel file con la seguente convenzione:

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.

Quale (penso) non è davvero difficile da localizzare in francese per (male da strettamente correlato) esempio di:

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>.

E un brutto esempio di pseudocodice del controller:

$customerServiceParagraph = getLocalizedText("customerServiceContact",$lang);
$customerSupportDescription = getTextContentByElementIdThenDelete("customer-support-description"));
linkify($customerServiceParagraph,"customer-support",$customerSupportDescription,"blabla","_blank");
mailto_ify($customerServiceParagraph, "specialist-name","XXX" );

Sono ben lungi dall'essere un esperto di localizzazione, ma penso che la scelta di liste ordinate o non ordinate sia una questione di convenzioni culturali, e quindi è anche parte del lavoro di team di localizzazione, anche se sono d'accordo che i tag sono un retaggio di vecchi sporchi collezione di tag stile / semantica di versioni html precedenti.

In generale, dovresti evitare di posizionare questi tag HTML nelle stringhe localizzate. Violenta il principio ASCIUTTO e vi è almeno una buona ragione per aderire qui: Immagina di avere non solo - diciamo - l'inglese e il francese, ma anche una pletora di altre lingue. Ora trovi un tag HTML per causare problemi. Dovrai modificare tutti i file di localizzazione, praticamente senza motivo. Se hai seguito il principio DRY fin dall'inizio, dovrai solo modificare un singolo file al meglio. Sfortunatamente lo stesso vale per altri markup.

Riguardo al tuo problema con l'ordine delle parole, questo è ovviamente un po 'più complesso. Continuo a pensare che dovresti esplodere le stringhe il più possibile, ma penso anche che ci sia un enorme vantaggio nelle etichette delle stringhe di localizzazione che sono più o meno auto-esplicative. Quindi forse dovresti abbandonare DRY e la coerenza in una certa misura e introdurre tag HTML in stringhe l13n quando è evitabile solo con un grande sforzo e il markup è improbabile che cambi. Altrimenti usa stringhe semplici.

Un altro pensiero: il metodo descritto sopra vale solo se si può assolutamente fidarsi delle proprie risorse. Se c'è solo la minima possibilità che qualcuno possa iniettare codice malevolo tramite le risorse l13n. Usa un altro markup che hai validato prima dell'inserimento (ok, dovrebbe funzionare anche con HTML, ma credo sia più facile con un markup più ristretto) o - se il tuo progetto lo consente - un formattatore come il tessile.

Con le implementazioni gettext in PHP utilizziamo la stringa stringa segnaposto per inserire contenuti variabili all'interno di testi traducibili.

Ad esempio, in WordPress ( __() è una funzione gettext specifica per WP utilizzata per estrarre le stringhe dal sorgente) puoi farlo:

$content = sprintf( __( 'Send us a message or %1$sview our contact information%2$s.' ), '<a href="...">', '</a>' );

Quale dà è una stringa sorgente .pot

Send us a message or %1$sview our contact information%2$s.

Dopo che PHP ha analizzato ed eseguito sprintf , ottieni il seguente risultato (ovviamente nella lingua desiderata):

Send us a message or <a href="...">view our contact information</a>.

In questo modo tutti i markup e altri dati non traducibili risiedono all'interno della logica dell'applicazione e restano fuori dai dati della stringa di traduzione. L'unico risultato è insegnare ai traduttori a copiare correttamente i segnaposto correttamente.

A seconda della tua implementazione puoi usare anche i segnaposti. L'implementazione personalizzata di sprintf non sarebbe poi così difficile. Quindi in sostanza la tua variante "BB-code" sarebbe la più vicina.

Il fatto che la soluzione 1 e la soluzione 2 siano entrambi meno che ideali mi ha fatto riflettere *. Ecco un tentativo di soluzione 4 (quella "d'oro") che non è solo un compromesso tra 1 e 2.

Gli obiettivi di questo approccio sono:

• I traduttori funzionano solo con il linguaggio naturale
• I traduttori traducono frasi intere significative, non parti del discorso troncate
• I programmatori controllano il markup
• L'architettura rispetta il principio ASCIUTTA

L'idea di base è chiedere ai traduttori di fornire sia una frase o frase completa, sia frasi di guida aggiuntive che il programmatore utilizzerà per aggiungere il markup in modo dinamico.

Quindi osservando il tuo esempio ** in cui l'output desiderato era

If you have a question, please ask our
  <a href="..." target="_blank" title="Customer support agent">Customer support agent</a>    
or write an email to our specialist, 
  <a href="mailto:...">Jane</a>.

Il traduttore fornirebbe questo XML:

<msg id="IfYouHaveAQuestion_body">
  If you have a question, please ask our Customer support agent or write an email to our specialist, Jane.
</msg>
<msg id="IfYouHaveAQuestion_link">Customer support agent</msg>
<msg id="IfYouHaveAQuestion_email">Jane</msg>

Senza usare il markup, il traduttore usa la seconda e la terza stringa per specificare quali parti della prima stringa devono essere marcate . Alla luce di questi suggerimenti, non è difficile per un programmatore assemblare l'output desiderato con metodi di manipolazione delle stringhe di base.

* La soluzione 3 non è molto diversa dalla soluzione 1, ma ha il vantaggio che il BBCode è una forma di markup più limitata rispetto all'HTML.

** Diversamente da questo esempio, il secondo esempio non è un caso difficile: il markup dell'elenco non deve andare nelle risorse di localizzazione.

Ricordo i commenti di Neil e di altri. Proprio come hai anche detto nel tuo secondo punto, non hai mai, mai voglia di dividere il messaggio in blocchi se stai localizzando il software. È un incubo per i traduttori (anche se accade regolarmente, quindi non li sorprenderebbe) e ritarderà la traduzione più di quanto tu possa mai immaginare a causa del tempo che impiegheranno i traduttori e gli esperti di QA per risolvere i problemi dovuti a disposizione di parole diverse e ordine in altre lingue. Influirà inoltre negativamente su altre parti del processo, inclusa la memoria di traduzione, che causerà il caos nelle future iterazioni delle stringhe di testo. I tag sono un problema irrisolto con la localizzazione. Abbiamo utilizzato diversi metodi per gestirlo, tra cui la protezione dei tag e l'uso di segnaposto nascosti, e quindi la ricostruzione del file dopo la traduzione, ma nessun metodo è perfetto. Idealmente, dovresti cercare di ridurre al minimo il tagging all'interno del testo il più possibile. Tuttavia, allo stesso tempo, i traduttori e le agenzie di traduzione sono abituati a gestire un certo livello di tagging all'interno del testo, quindi non è la fine del mondo se hai qualche tagging nei tuoi file.