Communitygithub.com

arabic-software-training-video

Produire ou améliorer des vidéos de formation logicielle en arabe à partir d’une application existante, d’un guide utilisateur ou d’une vidéo commentée. Couvre la capture d’interface réelle, la voix off et les sous-titres arabes, le mouvement progressif de focus, la musique originale, la production Python/FFmpeg modifiable et la QA documentée des médias.

Qu'est-ce que arabic-software-training-video ?

Cette compétence permet de transformer une interface applicative existante et sa documentation en une vidéo pas-à-pas pratique, révisable et modifiable. Elle est conçue pour les développeurs et formateurs qui souhaitent produire des tutoriels vidéo en arabe (dialecte standard principalement) avec une voix off naturelle, des sous-titres synchronisés, des annotations visuelles claires, et une qualité professionnelle. Le pipeline s’appuie sur Python, Playwright (Chromium), Pillow, FFmpeg, edge-tts, et d’autres outils open source vérifiés, sans supposer de services payants ni de GPU. Le processus inclut la création d’un storyboard structuré (JSON), la capture d’écran réelle avec protection des données, la génération de narration arabe avec reshape bidi, l’animation de flèches et zooms progressifs, la composition audio (musique originale, ducking), et une phase de revue qualité détaillée (vérification des sous-titres, des timings, des niveaux audio, et des éléments d’interface). Les livrables incluent la vidéo finale, les sous-titres SRT, les fichiers audio séparés, un rapport qualité PDF, et un projet éditable complet. Cette compétence ne doit pas être utilisée pour reconstruire une application ou créer des vidéos promotionnelles génériques.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Mustafa1998-tech/user-guide-video-skill/tree/HEAD

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Vidéo de guide utilisateur d'application en arabe

Transformer l'interface et la documentation d'une application existante en une démonstration pratique pouvant être révisée et modifiée. Chaque instruction doit faire référence à un élément d'interface réel. Toute affirmation de qualité doit être étayée par une vérification réelle.

Établir le périmètre et les références

  • Lire la demande de l'utilisateur et les pièces jointes avant de choisir un style de production. Identifier la langue ou le dialecte, le branding, les livrables et les limites d'affichage des données.
  • Inspecter la vidéo précédente, la narration source, les sous-titres et le timing lorsqu'ils sont disponibles. Distinguer le script source approuvé d'une transcription déduite de l'audio.
  • Considérer l'application actuelle comme faisant autorité pour les fonctionnalités, les noms de champs, les boutons et les routes. Utiliser les images fournies et les modèles officiels comme références visuelles.
  • Réutiliser un projet de production modifiable lorsqu'il est disponible plutôt que de recapturer du matériel correct inutilement.
  • L'arabe standard moderne est la langue par défaut pour le contenu arabe institutionnel. Respecter une demande explicite pour un autre dialecte ; ne pas mélanger les styles dans une même version.
  • Une demande de production vidéo n'autorise pas les modifications du code de l'application, des autorisations, du réseau ou des données de production, ni la publication ou l'envoi de contenu à d'autres personnes.

Choisir les outils disponibles

Utiliser les outils réellement disponibles. Ne pas supposer l'existence d'un service vocal, d'une clé API ou d'un GPU.

OutilObjectif
Python et un environnement virtuelOrganiser et exécuter le pipeline de production
Playwright + ChromiumCapturer l'interface réelle et tester la lecture
PillowImages, titres, calques, pointeur et positions de focus
NumPyTraitement audio ou musique procédurale originale
FFmpeg, localement ou via imageio-ffmpegMouvement, composition, encodage et traitement audio
edge-tts ou un fournisseur autoriséNarration et timing des limites de mots
arabic-reshaper et python-bidiRétablissement de la forme arabe lorsque RAQM est indisponible
PyAVDurée des médias, nombre d'images et vérification des clips
faster-whisperTranscription locale optionnelle pour révision lorsque les ressources le permettent
openpyxlEnregistrement de la prononciation et de la révision
HTML/Chromium ou un outil PDF adaptéRapport qualité arabe lisible

Vérifier la compatibilité Python/paquets avant d'installer les dépendances. Utiliser un environnement isolé et enregistrer les versions. Obtenir les polices auprès de leurs sources officielles et conserver les licences.

Créer un storyboard modifiable

Utiliser des données structurées telles que storyboard.json. Pour chaque étape, enregistrer :

  • Chapitre, titre de l'étape, script parlé et capture requise.
  • L'élément à mettre en évidence et si le mouvement illustre une capture d'écran ou enregistre une action réelle.
  • La preuve soutenant l'instruction, tout délai d'attente, et le résultat réel le cas échéant.

Écrire des phrases courtes qui expliquent une action à la fois. Conserver les libellés d'interface tels qu'affichés. Ne pas lire chaque mot visible pour remplir le temps, ni omettre les explications nécessaires pour raccourcir la vidéo.

Appliquer des diacritiques arabes partielles sur les mots ambigus, en particulier les noms de produits, les noms d'organisations et les termes techniques. Maintenir un dictionnaire de prononciation modifiable. Les seuls diacritiques textuels ne prouvent pas que la parole générée est prononcée correctement.

Capturer l'interface et protéger les données

  1. Capturer l'interface réelle à une résolution permettant un zoom lisible. Utiliser un ratio de pixels d'affichage approprié plutôt qu'un sur-échantillonnage par IA.
  2. Enregistrer les rectangles des éléments cibles et les décalages de rognage avec les captures, ainsi que les dimensions de la zone d'affichage et le ratio de pixels d'affichage.
  3. Examiner les libellés, valeurs, infobulles, liens et le compte visible, pas seulement les champs remplis.
  4. Utiliser un environnement de formation ou un masquage documenté dans l'aperçu. Ne pas modifier les données de production uniquement pour créer une capture d'écran sûre.
  5. Étiqueter les informations substituées comme des exemples. example.org et 192.0.2.10 peuvent remplacer les liens et adresses opérationnelles.
  6. Le mouvement du pointeur ou le zoom sur une capture d'écran fixe est une illustration, pas un enregistrement en direct. Le décrire avec précision.
  7. Pour capturer une sauvegarde réussie authentique, utiliser un environnement de test isolé autorisé et vérifier d'abord la destination d'écriture. Nettoyer les enregistrements de test par la suite. Si indisponible, expliquer la procédure sans fabriquer un message de succès.

Ne pas envoyer de captures d'écran d'application ou de données à un fournisseur de narration. Envoyer uniquement le texte explicatif général, en respectant les restrictions de l'utilisateur sur le traitement externe.

Narration et sous-titres arabes

  • Vérifier la disponibilité de la voix et tester un passage représentatif. Un identifiant de voix régional n'établit pas en soi le dialecte, l'arabe formel ou une expression naturelle.
  • Conserver le texte approuvé, l'audio et les limites de mots pour chaque segment. Régénérer uniquement les segments modifiés.
  • Dériver les clés du cache audio du texte, de la voix, du débit et des réglages de prononciation ; la seule existence du fichier n'est pas une clé de cache valide.
  • Construire le SRT à partir du script approuvé, en conservant la ponctuation, et aligner ses mots avec les limites de temps. Ne pas assembler des jetons de transcription bruts et perdre la ponctuation.
  • Documenter l'estimation du timing lorsque l'alignement exact n'est pas disponible. Ne pas le décrire comme une vérification précise basée sur l'écoute.
  • Vérifier le rendu arabe. Préférer la mise en forme native avec RAQM ; utiliser reshaper/bidi uniquement si nécessaire. Ne pas mettre en forme ni inverser le texte deux fois.
  • Tester la police avec l'arabe, les chiffres et le texte technique mixte. Éviter les sous-ensembles de polices incomplets.
  • Positionner les sous-titres en dehors de la zone d'action importante. Les garder lisibles à la taille d'un téléphone et de préférence sur une ou deux lignes.

Mouvement et branding

  • Extraire les couleurs, polices et logos du projet réel. Utiliser le logo original sans le redessiner ni le recoloreur.
  • Montrer clairement l'instruction en cours plutôt que d'encombrer toutes les instructions autour d'une petite capture d'écran.
  • Zoomer progressivement sur l'action tout en préservant le rapport hauteur/largeur et la totalité du champ ou du bouton concerné.
  • Utiliser un pointeur clair, un mouvement atténué et une brève indication de clic lorsque cela est utile. Aligner le clic avec l'instruction parlée correspondante.
  • Garder les transitions calmes. Éviter les secousses, les flashs et les zooms répétés sans but.
  • Lorsqu'une introduction et une conclusion sont demandées, utiliser la même identité et révéler progressivement le logo, l'organisation et le titre. Des durées telles que 8 à 12 secondes sont des exemples, pas des exigences universelles.
  • Ne pas présenter un slogan proposé comme un slogan officiellement approuvé.

Flèches : couleur, placement et mouvement

Ce sont des valeurs par défaut de production recommandées, pas des affirmations sur chaque vidéo existante. Les adapter à la densité de l'application et à la référence de l'utilisateur tout en conservant un style d'annotation cohérent tout au long d'une livraison.

Apparence

  • Utiliser le rouge #D52424 pour la flèche d'instruction, avec un contour blanc #FFFFFF pour la séparer des interfaces claires et sombres. Conserver les couleurs et le logo de l'application inchangés.
  • En 1920×1080, commencer avec un fût de 5 px, un contour blanc de 2 px, une tête de flèche de 18 px et une longueur totale d'environ 90–160 px. Mettre ces valeurs à l'échelle proportionnellement à la résolution de sortie et vérifier la lisibilité à la taille d'un téléphone.
  • Une petite ombre noire à environ 18 % d'opacité avec 3 px de flou est optionnelle. Ne pas ajouter de lueur néon, d'effets 3D lourds, d'emoji ou d'un glyphe de flèche textuel. Dessiner l'annotation comme un chemin vectoriel propre ou un calque transparent haute résolution.
  • Distinguer la flèche du didacticiel du pointeur de la souris réel : la flèche explique la cible ; le pointeur indique la navigation ou un clic réel. Éviter d'afficher les deux lorsqu'ils masquent la même commande.

Placement et coordonnées

  • Pointer vers le bord du bouton, du champ ou du lien réel, en laissant environ 6–12 px de dégagement en Full HD. Ne pas couvrir son libellé, sa valeur tapée, son icône, son contour de focus, son message de validation ou les sous-titres.
  • Préférer un chemin diagonal ou une courte courbe depuis un espace vide voisin. Afficher une flèche d'instruction par action. Pour plusieurs actions, révéler les flèches séquentiellement plutôt que de laisser une collection à l'écran.
  • Enregistrer un rectangle cible et une ancre relative à la capture source. Appliquer le même rognage, mise à l'échelle, panoramique et zoom à la pointe de la flèche qu'à la capture d'écran. Ne jamais coder en dur une coordonnée d'écran fixe pour un zoom animé.
  • Avant un zoom/pan supplémentaire, un simple mappage rognage-échelle est screenX = offsetX + échelle * (sourceX - cropX) et de même pour Y. Appliquer également toute transformation d'animation ultérieure et vérifier l'image encodée réelle.
  • Le sens RTL/LTR affecte la disposition du texte d'annotation, pas l'emplacement réel de la cible. Ne pas inverser automatiquement une flèche simplement parce que la langue de narration change.

Timing et mouvement

  1. Laisser l'écran concerné se stabiliser. Fondu de la flèche sur environ 0,15–0,25 seconde.
  2. Si le mouvement aide à expliquer l'action, déplacer la pointe vers sa cible une fois sur environ 0,35–0,65 seconde en utilisant un mouvement atténué. Ne pas rebondir, secouer, faire tourner ou répéter le mouvement en continu.
  3. Une fonction d'atténuation utile est e = (1 - cos(pi * u)) / 2, où u est la progression écoulée limitée à 0–1. Interpoler la position en utilisant p = début + (fin - début) * e. Pour un chemin courbe, évaluer la courbe à progression atténuée et orienter la tête de flèche le long de sa tangente.
  4. Terminer le mouvement lorsque le narrateur nomme la cible ou dit « cliquez ici ». Dériver cet indice de la chronologie de narration ou d'une limite de mot révisée ; ne pas appliquer le même délai arbitraire à chaque scène.
  5. Maintenir la flèche immobile pendant que le spectateur lit la commande et entend l'instruction. Un maintien de 1 à 2 secondes peut être un point de départ, mais l'instruction parlée et la lisibilité de la cible déterminent la durée réelle.
  6. Si un clic est représenté, montrer un seul anneau subtil pendant environ 0,3–0,5 seconde à la cible, synchronisé avec l'indice. Cette annotation ne doit pas impliquer qu'une action réelle ou une sauvegarde réussie a eu lieu alors que ce n'est pas le cas.
  7. Fondu de la flèche sur environ 0,15–0,25 seconde avant de changer de cible ou de scène. Dans une version à mouvement réduit, remplacer le déplacement/zoom par une flèche statique et un fondu doux ; éviter les pulsations ou les flashs.

Stocker la couleur, les dimensions, le rectangle source, l'ancre, le chemin, l'indice, la durée d'entrée, le maintien et la durée de sortie dans les paramètres du storyboard/rendu modifiables. Prévisualiser la flèche au début, pendant le zoom, à l'indice et à la fin. Confirmer qu'elle reste attachée au bon élément, dans le cadre, et lisible sur les deux thèmes sans masquer les sous-titres ni le contenu de l'interface.

Audio et musique

Utiliser une musique originale ou sous licence appropriée, en conservant sa source ou sa méthode de génération. Ne pas imiter une composition protégée spécifique.

Normaliser la narration et éviter l'écrêtage. Si la musique accompagne la parole, l'abaisser en fonction du signal de narration plutôt que de supposer qu'un niveau fixe est suffisant. Éviter la réduction du bruit sur une parole numérique propre lorsqu'elle endommage les consonnes.

Conserver les réglages de narration, de musique et de mixage séparés pour l'édition. Ne pas accélérer la parole pour respecter une durée arbitraire ; ajuster les scènes pour s'adapter à l'explication.

Détails du timing et de l'encodage

  • Mesurer l'audio à l'aide de PCM/WAV ou de nombres d'échantillons plutôt que d'une durée MP3 estimée.
  • Construire la timeline finale à partir des longueurs réelles des clips encodés ou des durées arrondies à la grille d'images. Inclure les séparateurs de chapitre et les pré/post-rolls audio.
  • Lier le SRT et les limites de chapitre à la timeline finale, et non à une timeline antérieure avec une dérive d'arrondi cumulative.
  • Inspecter les options de la version installée de FFmpeg. Ne pas supposer que filter_complex_script existe ; passer le graphe de filtres directement lorsque cela est approprié.
  • Écrire les durées décimales telles que 0.65 plutôt que .65 pour les filtres qui rejettent cette dernière.
  • Utiliser des chemins explicites et des arguments de sous-processus structurés. Ne pas construire de commandes shell à partir de la narration ou des titres de chapitre.
  • Invalider les caches de rendu lorsque les images, les rectangles cibles, les polices, les logos ou le code de mise en page changent.
  • Lors de l'exportation de chapitres autonomes, inspecter les limites des images clés et les débuts audio. Vérifier les fichiers extraits eux-mêmes.

Révision qualité et approbation véridique

Effectuer les vérifications appropriées au contenu :

  • Décoder la vidéo/l'audio complet et vérifier la résolution, le taux d'images, la durée et les pistes.
  • Mesurer le niveau sonore et les niveaux de crête ; vérifier les silences et l'écrêtage.
  • Comparer les sous-titres avec le script approuvé et valider l'ordre temporel et les limites finales.
  • Inspecter les images du rendu final réel, y compris l'introduction, la conclusion, les zooms, les messages de validation et les états de succès.
  • Tester la lecture et la recherche dans un navigateur ou un lecteur adapté, y compris un aperçu de la taille d'un téléphone.
  • Confirmer que chaque élément référencé existe, que la cible du focus est correcte et que le texte important n'est pas rogné.
  • Valider le PDF, le XLSX, les clips autonomes et le contenu de l'archive lorsque demandé.

La transcription automatique n'est pas une écoute. La reconnaissance vocale automatique peut identifier les passages nécessitant une révision, mais les divergences peuvent être des erreurs de reconnaissance ou des différences orthographiques.

Enregistrer les contrôles techniques, la comparaison textuelle automatisée, l'écoute documentée et l'approbation formelle séparément. Ne jamais marquer l'écoute ou l'approbation comme terminée à moins qu'elle n'ait eu lieu.

Si l'écoute directe ou humaine requise n'est pas disponible, l'indiquer clairement. Livrer les fichiers pris en charge et un enregistrement de révision d'écoute segment par segment ; ne pas revendiquer une prononciation parfaite. Ne pas signaler un changement basé sur la reconnaissance vocale comme une correction d'écoute confirmée.

L'enregistrement de prononciation doit inclure l'horodatage, le segment, le texte approuvé, la transcription ou le mot signalé, la correction demandée et le statut d'écoute/résolution.

Livraison

Suivre les noms et formats demandés. Une livraison complète peut inclure :

  • MP4 principal et introduction/conclusion séparées.
  • Narration WAV, SRT arabe et horodatages de chapitre.
  • XLSX de révision de prononciation et PDF de rapport qualité montrant les éléments vérifiés et en suspens.
  • Storyboard, captures sécurisées, polices/licences, ressources audio, code d'édition et informations de dépendances.
  • Clips de chapitre autonomes lorsque cela est utile.

Garder le projet d'édition portable ; exclure les chemins de la machine du développeur et les identifiants de connexion. Inspecter le paquet avant de créer une archive. Lier uniquement les fichiers qui existent, et indiquer les limitations du matériel sans revendiquer un travail non effectué.

Skills associés