Je travaille sur l'internationalisation des données saisies dans un client / serveur plutôt important (HTTP (HESSIAN) est utilisé pour la communication) Application stockée dans une base de données. Les utilisateurs peuvent choisir la langue qu'ils souhaitent voir et il existe une langue par défaut qui est utilisée lorsqu'une traduction dans la langue demandée n'est pas présente.
Actuellement, une classe de données peut ressembler à ceci: P>
public String getSomeText() {
return getSomeText(myThreadLocalLocale.get());
}
4 Réponses :
L'utilisation d'un fil local comme si vous décrivez est un modèle très courant dans les applications Web. Voir cette classe dans l'API Spring à titre d'exemple:
org.springframework.web.context.request.RequestContextHolder
Cette approche est parfaitement valide. Par exemple, le ressort rend les paramètres régionaux disponibles à l'aide de ThreadLocal via demandeContextListener et localecontextholder .
Si vous créez une implémentation personnalisée, assurez-vous de gérer correctement votre lecteur de fillocal (set / Supprimer) correctement.
Sachez que cette solution vous oblige à vous assurer de copier vos locaux de fil à chaque fois que vous passez à un autre fil. Quelque chose d'aussi simple que mycompletablefuture.ThenRunasync (...) vous fera perdre vos locaux de fil. Pire encore, vous risquez de changer de localisation de fil avec une autre demande qui fonctionne également thérunasync ou utilise Java.nio. * Ou fondamentalement tout code asynchrone.
Bien que, la pratique courante, je n'aime pas faire la localisation "profonde" dans l'application.
Obtenir de ceci: P>
<%= localizable.getString(locale) %>
ThreadLocal est une mauvaise pratique. Ce sont des variables globales et il y a beaucoup d'articles sur la taille de ce qui est, dans n'importe quelle langue. Le fait que le printemps utilise ne justifie pas l'utilisation. J'aime la solution Cruftex a donné. Évitez de transmettre des données via des variables globales.
Pourquoi utilisez-vous un ensemble pour
localizetringsstrings et non une carte?Avez-vous envisagé d'utiliser le printemps LocalContExtholder . Ses ressorts sont propres à stocker les paramètres régionaux actuels (stockés par le DispatcherServlet) pour un fil.
Si la fonction de votre variable de localisation est un seul thread, cela ressemble à une solution intelligente (et simple). Si vous vous aventurez à plusieurs threads, cela nécessite évidemment quelque chose de plus. Si votre API a des informations de localisation dans chaque demande, c'est une solution entièrement valide. Baiser, c'est le meilleur argument que vous puissiez faire.
@Jimmyt.: En raison des raisons qui ont à voir avec des mappages hibernate. Un autre problème intéressant, mais ne fait pas partie de la question ici.
Mais Hibernate soutient très bien les cartes.