Comment gérer la tâche de révision des chaînes localisées par un non-développeur?

Dans .NET Framework, les chaînes localisées sont situées dans un fichier XML (ou plusieurs fichiers). Ces fichiers font partie du projet et sont validés pour le contrôle de code source comme tout autre fichier de code source. Généralement, Visual Studio est utilisé pour afficher ces fichiers sous forme de tableau et modifier les chaînes localisées.

Je travaille en petite équipe sur un produit qui devrait avoir une interface multilingue.

1. En tant que développeur, je rédige les chaînes localisées dans les deux langues, étant donné que la traduction peut être inexacte,

2. Une autre personne de l'équipe (un non-développeur) examine le contenu dans les deux langues et le corrige si nécessaire.

Le problème actuel est que la personne non développeur n'utiliserait ni le contrôle de code source, ni un IDE, car ce serait trop lourd et difficile (le contrôle de version est difficile pour les non développeurs) pour cette personne.

Une solution alternative serait pour moi d'exporter les chaînes localisées sous forme de fichier Excel, d'attendre que cette personne examine Excel, puis de réimporter les chaînes modifiées. La mise en garde ici est que je peux créer d'autres chaînes, renommer des chaînes existantes, etc., ce qui rend difficile la différence entre la version locale et la version révisée.

Que faire?

Comment ça se passe dans les autres équipes?

La localisation est beaucoup plus complexe que la simple modification de XML dans Visual Studio, en particulier:

1. Bien que ce que KateGregory dit soit correct, Visual Studio coûte cher et l'achat de copies pour les localisateurs est souvent prohibitif.
2. À moins que le localisateur ne soit également un développeur, il ne peut pas voir les chaînes dans le produit et tester que les chaînes s'affichent correctement (caractères non européens comme les langues asiatiques ou texte de droite à gauche comme l'arabe), ajuster / enrouler correctement (allemand mots) et ne provoquent pas d'attaques par injection (comme l'utilisation d'apostrophes en français)
3. Bien que le contrôle de version ne soit pas un outil complexe, donner accès au contrôle de source à des localisateurs distants ou sous contrat représente un risque. Ils pourraient copier le code source à l'insu de l'équipe ou commettre des modifications de rupture (intentionnellement ou non).
4. Il suppose également que la seule chose que vous localisez est les fichiers RESX. Certains produits peuvent avoir des données localisées comme les noms de rapports.

Par conséquent, la meilleure chose à faire est de créer un site Web simple qui expose les différentes chaînes, masquant la syntaxe sous-jacente. Le processus de génération comprend des chaînes fournies par les localisateurs après un rapide contrôle de cohérence et la génération partagée avec les localisateurs pour les tests. Le site Web peut utiliser des connexions pour différents localisateurs (et suivre et facturer le travail si vous voulez aller aussi loin). C'est plus de travail mais une meilleure solution à long terme.

L'édition de XML craint. Visual Studio dispose d'une vue que vous pouvez utiliser pour modifier des ressources:

Je pense que le check-out-on-edit combiné à une minute de démonstration de la fenêtre "modifications en attente" devrait permettre à votre non-développeur d'utiliser autant de contrôle de code source qu'il le souhaite.

Je chercherais à trouver un éditeur XML * pour les non-développeurs à utiliser.

Vous devrez ensuite fournir des extraits versionnés au non-développeur pour examen.

Une fois la vérification terminée, vous pouvez réarchiver le fichier.

Une fois les modifications apportées, il vous suffit de différencier les fichiers XML avant l'enregistrement et d'envoyer les sections mises à jour par vous-même au non-développeur pour examen. Vos mises à jour expliquent pourquoi vous devez conserver les fichiers de révision versionnés.

Essayer d'utiliser Excel rendra les choses extrêmement difficiles car les outils de diff pour Excel laissent beaucoup à désirer. Vous courez également le risque que des commentaires supplémentaires se glissent dans les cellules supplémentaires de la feuille de calcul. Ces commentaires nécessiteraient un traitement supplémentaire de votre part afin de les réintégrer.

Dans une vie antérieure, nous avons utilisé un processus assez similaire pour un certain nombre de traductions par des organisations externes. Nos fichiers étaient essentiellement des fichiers texte avec une forme similaire mais différente de XML. Et nous avons eu des tonnes de changements pendant que les fichiers étaient en cours de révision, donc j'apprécie le plaisir de votre situation.

Une option consiste à créer une application d'aide dans laquelle le traducteur peut voir la liste des chaînes dans un volet et entrer la langue spécifique dans un autre. De cette façon, les données sont stockées dans le XML, puis vous pouvez demander à cette application d'exporter le fichier.

Si vous traitez les clés dans une base de données et y stockez chaque langue, cela permettrait aux modifications d'être intégrées et au traducteur de voir ce qui doit être mis à jour. Ensuite, vous pouvez simplement exporter vers le fichier XML spécifique à la langue que vous remettez dans le contrôle de version ou le traducteur pourrait.

Nous utilisons une méthode similaire à celle-ci avec notre code Rails, nous n'éditons jamais ou même fournissons les fichiers spécifiques à la langue, ils sont tous maintenus puis exportés par l'application externe que notre équipe de traduction utilise. Désolé, je ne sais pas si leur logiciel est personnalisé ou standard, mais il ne devrait pas être si difficile de rassembler quelque chose de simple.

Comment savez-vous que vous avez obtenu toutes les chaînes et qu'elles sont correctement formatées dans l'application? Comment savez-vous que les nombres, la devise, le fuseau horaire et les autres informations locales sont formatés correctement? Que tout est chargé et que la sérialisation multi-octets fonctionne correctement?

Non. La localisation est une fonctionnalité comme les autres. Enregistrez-le. Faites une construction. Laissez le testeur obtenir la version et vérifiez que la fonctionnalité est correctement exécutée comme les autres. Lorsque vous créez une nouvelle version, vous pouvez effectuer des tests de régression sur la localisation - comme toute autre fonctionnalité.