Di cosa parlano i messaggi di errore? Se stai parlando di eccezioni, ovvero errori che sembrano come "Riferimento oggetto non impostato su un'istanza di un oggetto", questi errori dovrebbero essere letti dagli sviluppatori solo , e mai essere mostrato agli utenti finali. Ciò significa che la loro traduzione non ha senso.
Come fornitore di un'API, di solito non devi preoccuparti delle traduzioni, sarebbero messaggi di errore o qualsiasi altra cosa. Fornisci data e appartiene all'applicazione che utilizza questi dati per mostrarli attraverso un'interfaccia visiva che, spesso, dovrebbe essere internazionalizzata e localizzata.
Alcuni esempi:
-
Se la tua API ha una data da inviare a un cliente, verrà formattata in un formato cultura non ambiguo e neutrale, ad esempio 2016-12-24T14: 37: 06.58247Z. Quindi, l'applicazione può mostrarlo in un formato che è effettivamente adatto per l'utente, incluso, ad esempio, il giorno della settimana o il mese nel testo completo e tradotto nella lingua di scelta dell'utente.
-
Se la tua API ha un numero in virgola mobile, verrà serializzata su JSON come 1725.38, quindi l'app la mostrerà, ad esempio, come "1.725,38" per un utente francese.
In casi molto rari, devi preoccuparti delle traduzioni. A volte, non si traducono i dati, ma si inviano le traduzioni separatamente (ad esempio come file JSON che associa le chiavi ai valori per una cultura specificata nella richiesta HTTP). Oppure traduci i dati effettivi. Oppure invii i dati grezzi e tradotti fianco a fianco.
Se la tua API appartiene a quei casi rari, la scelta di presentare i dati dovrebbe essere guidata dai requisiti e dai vincoli definiti dal proprietario del prodotto o, in ultima analisi, dai clienti. Se non sono d'accordo, spetta al proprietario del prodotto decidere se segui quelli o gli altri o sviluppare due API.