Je recherche un outil, une fourchette de fourmis, un plugin IDE, ... qui aide avec I18N d'un Application Java à l'aide des ensembles de ressources de messages-messages standard. Les deux Les solutions open source et commerciales sont les bienvenues.
Spécifiquement, je cherche une assistance dans les tâches suivantes:
1) Extraire les clés utilisées du code Java, des JSP et d'autres artefacts. Depuis la coutume Les cadres sont impliqués que l'extraction devrait permettre la personnalisation.
Mappage de l'artefact source à un ensemble de messages de certains messages. Aussi avec des règles personnalisées.
Signaler les clés utilisées qui ne sont pas dans le paquet. Clés de rapport qui sont dans le paquet Mais dans aucun de l'artefact source qui mappe sur ce paquet.
2) Cochez la page Fichiers de propriétés de chaque paquet et signaler les définitions de clé manquantes et également les traductions par défaut (utilise le texte anglais).
3) Comparez la version actuelle SVN / CVS / Quelle que soit la version avec une ancienne version et un rapport cas où une traduction (ou peut-être que seul le par défaut) a changé mais pas le autre traduction.
http://rscbundlecheck.sourceforge.net/ couvre 2) à une grande partie. Cependant, je n'ai pas trouvé quelque chose pour 1) et 3). Tous les pointeurs?
3 Réponses :
Signaler les clés utilisées qui ne sont pas dans le paquet. Clés de rapport qui se trouvent dans le paquet mais dans aucun de l'artefact source qui correspondent à ce paquet.
Vous savez, celui-ci est assez typique et je doute que tout cadre inclue l'inclure, car elle nécessite une analyse du code et de déterminer, quels appels sont appels au faisceau de ressources, qui peuvent être des chaînes dynamiques passées comme des arguments, etc.
Normalement, les paquets sont édités à l'aide de l'éditeur dédié, F.G. Plugin de ressourcesBundle pour Eclipse, dans lequel vous modifiez simultanément l'original et la traduction, et que vous voyez des avertissements pour chaque clé non présente dans toutes les traductions.
1) Extraire les clés utilisées du code Java, des JSP et d'autres artefacts. Comme les cadres personnalisés sont impliqués, l'extraction devrait permettre personnalisation.
Mappage de l'artefact source à un ensemble de messages de certains messages. Aussi avec règles personnalisées.
J'ai également fait face à ces mêmes problèmes et j'ai commencé à développer une nouvelle solution. Je viens de Publié c'est aujourd'hui dans mon blog. Il utilise simplement l'outil Java Annotation Processor pour créer (ou simplement mettre à jour) les fichiers de propriétés et les clés. Il est également extensible, comme décrit dans le poteau. Et il est disponible dans mon projet GitHub (vous devrez trouver le lien de mon blog, car je ne peux pas publier plus de 2 liens).
N'hésitez pas à l'utiliser et à demander ce dont vous avez besoin.
2) Vérifiez les fichiers de propriétés de chaque paquet et signaler une clé manquante définitions et également traductions par défaut (utilise le texte anglais).
J'ai aussi trouvé cette solution (ne l'a pas encore essayé), et cela semble prometteur!
J'espère que cela aide!
J'ai implémenté le compilateur de messages à cet effet, ce qui crée les fichiers de référence de ressources et Définitions constantes comme Java Enum pour les touches d'un seul fichier source. Donc, les constantes peuvent être utilisées dans le code source Java , qui est une manière beaucoup plus sûre. Le compilateur de messages ne peut être utilisé que pour Java . Il crée également des fichiers de ressources et des constantes pour Objective-C ou Swift et peut être étendu à d'autres environnements de programmation.
Avez-vous de la chance avec la recherche de la solution?