Progettazione delle best practice dell'API per la localizzazione - hanno bisogno di risultati localizzati e non localizzati

3

Ho 2 tipi di utenti della mia API: quelli che vogliono messaggi di errore tradotti e quelli che non lo fanno. Ho provato finora 2 modi:

  1. restituisce sia i messaggi tradotti che quelli non tradotti ( link ). Non mi piace perché è meno efficiente sia in termini di spazio che di memoria.
  2. Permetti al chiamante di tradurlo da solo. Questo è disordinato come diamine ( link ).

Quali sono le migliori pratiche per farlo?

    
posta Vadi 20.04.2017 - 20:28
fonte

2 risposte

1

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.

    
risposta data 20.04.2017 - 20:54
fonte
1

Opzione 3:

  • fornisce una funzione nella tua API che rende facile per il chiamante la traduzione di un messaggio di errore non tradotto, se lo desidera.

Questa potrebbe essere una funzione di traduzione nella tua API che viene chiamata in seguito (con il messaggio di errore non tradotto o un codice di errore come input) o una determinata modalità o stato della tua API (specifica per il chiamante). Dipende dai dettagli della tua API quale dei due approcci avrà più senso.

    
risposta data 21.04.2017 - 06:35
fonte

Leggi altre domande sui tag