Voir les fichiers modifiés dans Studio

Utilise ceci avant de committer une exécution : tu vois quels fichiers de locale une exécution de traduction ou une modification a touchés, et quelles clés ont changé dans chacun, sans quitter Studio. Studio ne fait que lire ; il ne fait jamais de stage, de commit ni de restauration.

Ouvre la section ChangesCopier le lien vers cette section

Démarre Studio (Réviser dans Studio) et descends sur la page Overview jusqu'à Changes, sous le tableau des locales. Elle indique la branche active (ou Detached HEAD) et liste chaque fichier qui diffère du dernier commit, dix par dix et avec Show all N files pour le reste :

Tes fichiers de locale source et cible sont listés, ainsi que verbatra.lock.json et verbatra.provenance.json, qui affichent un état et aucun changement de clés. Un projet propre indique qu'aucun fichier de locale ne diffère.

Lis les changements de clésCopier le lien vers cette section

Key changes (de) ouvre le fichier de cette locale sous forme de clés, comparé au dernier commit : les clés Changed avec l'ancien et le nouveau texte côte à côte, les clés Added et les clés Removed. Appuie de nouveau sur le bouton pour fermer ; une seule locale est ouverte à la fois. Une clé modifiée ou ajoutée que la source possède aussi renvoie vers son entrée dans Translations.

• Un fichier, plusieurs locales : un catalogue comme apple-xcstrings garde toutes les locales dans un fichier, donc il a un bouton par locale. Chacun compare cette locale seulement.
• Longues listes : une liste contient au plus 500 clés et chaque texte est coupé à 2000 caractères. Quand cela arrive, Studio dit que la liste est incomplète et marque un texte coupé ; la différence complète se trouve dans git. Une longue liste montre 50 clés à la fois.
• Seul l'ordre a changé : un fichier modifié aux mêmes clés et textes le dit.
• Conflits : un fichier avec des conflits de fusion non résolus affiche son état et aucun changement de clés. Résous d'abord les conflits dans git.
• Texte sûr : les clés et les valeurs s'affichent en texte brut, dans la langue et le sens de la locale, jamais comme du balisage.

Quand il n'y a rien à montrerCopier le lien vers cette section

Studio explique au lieu de lever une erreur quand il ne peut pas comparer, par exemple quand :

• le projet n'est pas dans un dépôt git, ou git n'est pas installé ou trop ancien pour un clone partiel ;
• git refuse le dossier parce qu'un autre utilisateur en est propriétaire, ou que le dossier est dans un dépôt bare ;
• le dépôt configure un filtre de contenu que Studio n'exécute pas ;
• un files.pattern place un fichier de locale hors du dossier du projet, par exemple avec ../, si bien qu'une liste pourrait omettre ce fichier.

Une lecture trop longue ou échouée affiche l'erreur de la page avec son Retry. Un projet au format custom: montre ses fichiers modifiés mais jamais leurs changements de clés : Studio compare le fichier commité aux seuls adaptateurs de format intégrés, qui ne peuvent pas exécuter un adaptateur personnalisé. Voir Écrire un adaptateur de format personnalisé.

Sache à quel point c'est à jourCopier le lien vers cette section

La section relit quand un fichier de locale, de verrouillage ou de provenance change sur le disque, quand l'index ou HEAD de git change (un commit, un changement de branche, un reset ou git add) et quand tu reviens sur l'onglet ou la fenêtre de Studio. Si une lecture échoue, Studio garde la dernière réponse et le dit.

Ton propre code dispose des mêmes lectures sous le nom localeGitStatus et localeGitDiff, qui énumèrent chaque raison pour laquelle une comparaison peut être indisponible et les garde-fous git appliqués.