HB of localized readme files

README-localized/README-es-es.md

@@ -0,0 +1,101 @@
+# Tabla de contenido
+- [Tabla de contenido](#table-of-contents)
+- [Intune-PowerShell-SDK-Code-Generator](#intune-powershell-sdk-code-generator)
+- [Colaboradores](#contributing)
+- [Diseño](#design)
+    - [Arquitectura de alto nivel](#high-level-architecture)
+    - [El paso de generación automática](#the-auto-generation-step)
+- [Trabajos futuros](#future-work)
+- [Preguntas frecuentes](#faq)
+    - [¿Dónde está el código generado?](#where-is-the-generated-code)
+    - [¿Por qué necesitamos este módulo de PowerShell?](#why-do-we-need-this-powershell-module)
+    - [¿Por qué queremos generar automáticamente el módulo de PowerShell?](#why-do-we-want-to-auto-generate-the-powershell-module)
+    - [¿Por qué la compilación está siendo realizada por Intune (y por qué no la está realizando el equipo SDK de Graph)?](#why-is-intune-building-it-and-why-isnt-the-graph-sdk-team-building-it)
+    - [¿Qué es Vipr?](#what-is-vipr)
+    - [¿Por qué un escritor personalizado?](#why-a-custom-writer)
+    - [¿Por qué no usar OpenAPI y Swagger?](#why-not-use-openapi-and-swagger)
+
+# Intune-PowerShell-SDK-Code-Generator
+Este repositorio implementa el escritor de Vipr que genera cmdlets de PowerShell para todas las operaciones CRUD, las funciones y las acciones para compatibilidad con la API de Graph en Microsoft Intune.
+
+# Colaboradores
+Este proyecto recibe las contribuciones y las sugerencias. La mayoría de las contribuciones requiere
+que acepte un Contrato de Licencia de Colaborador (CLA) donde declara que tiene el derecho, y realmente lo tiene, de otorgarnos los derechos para usar su contribución.
+Para obtener más información, visite https://cla.microsoft.com.
+
+Cuando envíe una solicitud de incorporación de cambios, un bot de CLA determinará automáticamente si necesita proporcionar un CLA y agregar el PR correctamente (por ejemplo, etiqueta, comentario).
+Siga las instrucciones proporcionadas por el bot.
+Solo debe hacerlo una vez en todos los repositorios que usen nuestro CLA.
+
+Este proyecto ha adoptado el [Código de conducta de código abierto de Microsoft](https://opensource.microsoft.com/codeofconduct/).
+Para obtener más información, vea [preguntas frecuentes sobre el código de conducta](https://opensource.microsoft.com/codeofconduct/faq/)
+o póngase en contacto con [opencode@microsoft.com](mailto:opencode@microsoft.com) si tiene otras preguntas o comentarios.
+
+# Diseño
+## Arquitectura de alto nivel
+![Arquitectura de alto nivel](Design.jpg)
+esta es la información general sobre cómo se junta el módulo de PowerShell.
+1. El Vipr.exe es ejecutado con los siguientes argumentos para generar el código que definirá el comportamiento de los cmdlets.
+- Los resultados de la compilación del proyecto GraphODataPowerShellWriter (es decir, GraphODataPowerShellWriter.dll).
+- Un esquema de Graph (por ejemplo, el resultado de llamar a https://graph.microsoft.com/v1.0/$metadata) - este archivo tiene la extensión ".csdl" y se encuentra en "~/TestGraphSchemas".
+2. La documentación generada en la salida de Vipr es extraída en un archivo XML. PowerShell usa el archivo XML para mostrar el resultado del cmdlet "Get-Help".
+3. Estos cmdlets se escriben en sus propios módulos, debido a que algunas funcionalidades cobran más sentido al ser escritas a mano en PowerShell. Estos módulos se encuentran en "~/src/PowerShellGraphSDK/PowerShellModuleAdditions/CustomModules".
+4. Los resultados de los tres pasos anteriores (es decir, los cmdlets generados, la documentación del cmdlet y los cmdlets escritos a mano) se combinan al usar un archivo de manifiesto de PowerShell. Este archivo tiene la extensión ".psd1".
+5. El archivo de manifiesto de PowerShell creado en el paso anterior se utiliza para importar y utilizar el módulo. Por ejemplo, si el archivo de manifiesto se llamó "Intune.psd1", puede ejecutar "Import-Module ./Intune.psd1" en una ventana de PowerShell para importar el módulo.
+
+## El paso de generación automática
+![ genera el módulo binario de PowerShell](Generating_the_PowerShell_Binary_Module.jpg)
+este es un examen detallado del paso 1 en la sección de[arquitectura de alto nivel](#high-level-architecture).
+- El archivo de definición de esquema (CSDL) se carga en Vipr.
+- La v4 del lector OData está incorporada en Vipr y se usa para leer el archivo CSDL. Este lector convierte la definición del esquema en una representación intermedia, denominada modelo ODCM.
+- El escritor personalizado se pasó a Vipr para procesar el modelo ODCM. Para convertir el modelo ODCM en los archivos C# finales generados, el escritor consta de 4 pasos:
+1. Recorra el modelo de ODCM (es decir, el esquema) para detectar todas las rutas.
+2. Cree una representación abstracta de los cmdlets de cada una de las rutas que representan las operaciones en cada una.
+3. Convertir todas las representaciones cmdlet abstractas en una representación C# abstracta.
+4. Convierta cada representación C# abstracta en una cadena que se escribirá como el contenido de un archivo.
+
+# Trabajos futuros
+- [ ] Mejorar los nombres de los cmdlets generados.
+    - [ ] Ver si podemos agregar anotaciones al esquema de gráficos que se puedan usar para crear nombres descriptivos para las rutas.
+- [ ] Buscar un método para generar y crear cmdlets para todo el esquema de gráficos en una cantidad de tiempo razonable.
+    - El número de rutas (debido a las propiedades de navegación) aumenta considerablemente una vez que las entidades de AAD son incluidas.
+- [ ] Obtener la documentación de ayuda generada del cmdlet para incluir el vínculo a la página correspondiente en la documentación oficial de Graph.
+- [x] Implementar la canalización de las salidas del cmdlet en otros cmdlets.
+- [ ] Implementar la autenticación no interactiva.
+    - [ ] Autenticación con certificados.
+    - [x] Autenticación con un objeto PSCredential.
+- [x] Asegurarse de obtener el tiempo de expiración correcto del token de autenticación, el cual se controla cuando es necesaria la actualización automática del token.
+- [x] Crear un repositorio independiente para los cmdlets de escenario (que se serán usados como submódulo).
+- [ ] Travis CI de integración de GitHub y los casos de prueba.
+- [x] Crear un archivo de licencia para el software de terceros usado e incluirlo en el módulo.
+- [x] Actualiza el archivo \*.psd1 para incluir los vínculos correctos al correo público de GitHub, el archivo de licencia y el icono.
+- [x] Generar cmdlets de la aplicación de ayuda para crear objetos que se puedan serializar para los tipos definidos en el esquema.
+- [ ] Obtener las restricciones de capacidad agregadas de OData al esquema de gráficos para que los cmdlets que realizan operaciones no permitidas no sean generados en primer lugar.
+
+# Preguntas frecuentes
+## ¿Dónde está el código generado?
+GitHub: https://github.com/Microsoft/Intune-PowerShell-SDK
+
+## ¿Por qué necesitamos este módulo de PowerShell?
+Los clientes han expresado mucho interés en el uso de PowerShell para automatizar las tareas que se ejecutan actualmente con la extensión de Intune en el portal de Azure.
+
+## ¿Por qué queremos generar automáticamente el módulo de PowerShell?
+Si escribimos cada cmdlet manualmente, también tendríamos que actualizar el módulo manualmente cada vez que el esquema del gráfico sea actualizado.
+
+## ¿Por qué la compilación está siendo realizada por Intune (y por qué no la está realizando el equipo SDK de Graph)?
+La mayor parte de la base de usuarios de Intune (profesionales de la tecnología de la información) preferiría trabajar con PowerShell, mientras que el SDK de gráficos está dirigido a desarrolladores que preferirían trabajar con, por ejemplo, C#, Java y Python. Por esto lo necesitamos de forma urgente. La estructura de la sintaxis de PowerShell es incompatible con la estructura del actual generador de SDK de .Net/Java/Python (vea la explicación de por qué tenemos un [escritor personalizado de Vipr](#why-a-custom-writer)).
+
+## ¿Qué es Vipr?
+- La arquitectura es creada en torno a un proyecto de investigación de Microsoft denominado Vipr.
+- Generalizando el concepto de transformar la información de una sintaxis a otra.
+- Es esencialmente un analizador de texto modular que se adecua especialmente para las definiciones de servicio al estilo OData.
+- El ejecutable acepta un montaje de lector y uno de escritor.
+    - El lector está capacitado para analizar el archivo de entrada de texto en la representación (genérica) intermedia de Vipr.
+    - El escritor admite la representación intermedia y devuelve una lista de los objetos de archivo, es decir, pares de cadena o ruta de acceso.
+        - Luego, Vipr escribe estos archivos en la estructura de carpetas que le corresponde a la carpeta de salida.
+
+## ¿Por qué un escritor personalizado?
+No hay ningún escritor existente de PowerShell disponible para Vipr. Asimismo, el escritor del SDK de gráficos .Net/Java/Python no se prestará fácilmente a la sintaxis, el comportamiento o los procedimientos recomendados de PowerShell.
+
+## ¿Por qué no usar OpenAPI y Swagger?
+Esto podría haber sido posible, pero requeriría una transformación adicional del esquema OData de Graph al formato OpenAPI. Cada vez que se realiza una transformación, se corre el riesgo de perder información que podría ser valiosa en el módulo generado de PowerShell.

README-localized/README-fr-fr.md

@@ -0,0 +1,101 @@
+# Table des matières
+- [Table des matières](#table-of-contents)
+- [Intune-PowerShell-SDK-Code-Generator](#intune-powershell-sdk-code-generator)
+- [Contribution](#contributing)
+- [Conception](#design)
+    - [Architecture de haut niveau](#high-level-architecture)
+    - [Étape de génération automatique](#the-auto-generation-step)
+- [Travail futur](#future-work)
+- [FAQ](#faq)
+    - [Où se trouve le code généré ?](#where-is-the-generated-code)
+    - [Pourquoi ce module PowerShell est-il nécessaire ?](#why-do-we-need-this-powershell-module)
+    - [Pourquoi générer automatiquement le module PowerShell ?](#why-do-we-want-to-auto-generate-the-powershell-module)
+    - [Pourquoi est-il élaboré par Intune plutôt que par l’équipe du kit de développement logiciel (SDK) Graph ?](#why-is-intune-building-it-and-why-isnt-the-graph-sdk-team-building-it)
+    - [Présentation de Vipr](#what-is-vipr)
+    - [Pourquoi utiliser un rédacteur personnalisé ?](#why-a-custom-writer)
+    - [Pourquoi ne pas utiliser OpenAPI et Swagger ?](#why-not-use-openapi-and-swagger)
+
+# Intune-PowerShell-SDK-Code-Generator
+Ce référentiel implémente le rédacteur Vipr qui permet de générer des cmdlets PowerShell pour toutes les opérations, fonctions et actions CRUD pour la prise en charge de l’API Microsoft Intune Graph.
+
+# Contribuer
+Ce projet autorise les contributions et les suggestions.
+Pour la plupart des contributions, vous devez accepter le contrat de licence de contributeur (CLA, Contributor License Agreement) stipulant que vous êtes en mesure, et que vous vous y engagez, de nous accorder les droits d’utiliser votre contribution.
+Pour plus d’informations, visitez https://cla.microsoft.com.
+
+Lorsque vous soumettez une requête de tirage, un robot CLA détermine automatiquement si vous devez fournir un CLA et si vous devez remplir la requête de tirage appropriée (par exemple, étiquette, commentaire).
+Suivez simplement les instructions données par le robot.
+Vous ne devrez le faire qu’une seule fois au sein de tous les référentiels à l’aide du CLA.
+
+Ce projet a adopté le [code de conduite Open Source de Microsoft](https://opensource.microsoft.com/codeofconduct/).
+Pour en savoir plus, reportez-vous à la [FAQ relative au code de conduite](https://opensource.microsoft.com/codeofconduct/faq/)
+ou contactez [opencode@microsoft.com](mailto:opencode@microsoft.com) pour toute question ou tout commentaire.
+
+# Conception
+## Architecture de haut niveau
+![Architecture de haut niveau](Design.jpg)
+Voici comment s’articule ce module PowerShell.
+1. Vipr.exe est exécuté avec les arguments suivants pour générer le code qui définit le comportement des cmdlets :
+– La sortie de génération du projet GraphODataPowerShellWriter (c-à-d : GraphODataPowerShellWriter.dll).
+– Un schéma Graph (ex : ce que renvoie https://graph.microsoft.com/v1.0/$metadata) ; l’extension de ce fichier est « .csdl », il est situé dans « ~/TestGraphSchemas ».
+2. La documentation générée comme donnée de sortie de Vipr est extraite vers un fichier XML. Ce fichier XML est ensuite utilisé par PowerShell pour afficher le résultat de la cmdlet « Get-Help ».
+3. Il est plus cohérent de taper certaines fonctionnalités manuellement dans PowerShell. Ces cmdlets sont donc écrites dans leurs propres modules. Ces modules sont situés dans « ~/src/PowerShellGraphSDK/PowerShellModuleAdditions/CustomModules ».
+4. Les résultats des trois étapes précédentes (c-à-d : les cmdlets générées, la documentation des cmdlets et les cmdlets manuelles) sont combinés selon un fichier manifeste PowerShell. L’extension de ce fichier est « .psd1 ».
+5. Le fichier manifeste PowerShell créé à l’étape précédente est ensuite utilisé pour importer et utiliser le module. Par exemple, avec un fichier manifeste « Intune.psd1 », exécutez « Import-Module ./Intune.psd1 » dans une fenêtre PowerShell pour importer le module.
+
+## Étape de génération automatique
+![Génération du module binaire PowerShell](Generating_the_PowerShell_Binary_Module.jpg)
+Ceci est un aperçu détaillé de l’étape 1 de la section [Architecture de haut niveau](#high-level-architecture).
+– Le fichier de schéma de définition (CSDL) est passé à Vipr.
+– Le lecteur OData v4 intégré à Vipr est utilisé pour lire ce fichier. Ce lecteur convertit la définition de schéma en une représentation intermédiaire appelée Modèle ODCM.
+– Notre rédacteur personnalisé est passé à Vipr pour le traiter. Le rédacteur effectue 4 étapes afin de convertir le modèle ODCM et générer les fichiers C# finaux :
+1. Parcours du Modèle ODCM (c-à-d le schéma) pour découvrir chaque route.
+2. Pour chaque route, création d’une représentation abstraite des cmdlets représentant chaque opération de la route.
+3. Conversion de chaque représentation abstraite de cmdlet en une représentation abstraite C#.
+4. Pour chaque représentation abstraite C#, conversion en une chaîne ensuite écrite comme contenu d’un fichier.
+
+# Travail futur
+- [] Améliorer le nommage des cmdlets générées.
+    - [] Ajouter si possible des annotations au schéma Graph pour la création de noms compréhensibles pour les routes.
+- [] Trouver un moyen de générer et intégrer des cmdlets pour le schéma Graph entier dans un délai raisonnable.
+    - Le nombre de routes augmente énormément lorsque des entités AAD sont incluses (en raison des propriétés de navigation).
+- [] Faire en sorte que la documentation d’aide de la cmdlet générée inclue un lien à la page appropriée de la documentation Graph officielle.
+- [x] Implémenter la canalisation des sorties vers d’autres cmdlets directement.
+- [] Implémenter l’authentification non-interactive.
+    - [] Authentification avec certificats.
+    - [x] Authentification avec un objet PSCredential.
+- [x] S’assurer d’obtenir la date d’expiration correcte du jeton d’authentification – Possible en rafraîchissant automatiquement le jeton quand c’est nécessaire.
+- [x] Créer un référentiel séparé pour les cmdlets de scénario (à fin d’utilisation comme sous-module).
+- [] Intégration Travis CI GitHub + cas de tests.
+- [x] Créer un fichier de licence pour les logiciels tiers utilisés et l’inclure dans le module.
+- [x] Mettre à jour le fichier \*.psd1 pour inclure les liens corrects vers le GitHub publique, le fichier de licence et l’icône.
+- [x] Créer des cmdlets d’assistance pour créer des objets pouvant être sérialisés dans des types définis dans le schéma.
+- [] Ajouter des Restrictions de Capabilité OData au schéma Graph afin que les cmdlets effectuant des opérations interdites ne soient tout simplement pas générées.
+
+# FAQ
+## Où se trouve le code généré ?
+GitHub : https://github.com/Microsoft/Intune-PowerShell-SDK
+
+## Pourquoi ce module PowerShell est-il nécessaire ?
+Les clients ont exprimé un grand intérêt dans l’utilisation de PowerShell pour automatiser des tâches actuellement exécutées par le biais de l’extension Intune dans le Portail Azure.
+
+## Pourquoi générer automatiquement le module PowerShell ?
+En tapant chaque cmdlet manuellement, il faut mettre à jour le module manuellement chaque fois que le schéma Graph est mis à jour.
+
+## Pourquoi est-il élaboré par Intune plutôt que par l’équipe du kit de développement logiciel (SDK) Graph ?
+La plus grande part de la base d’utilisateurs d’Intune (IT Professionals), préfèrent travailler avec PowerShell, alors que le kit de développement logiciel Graph vise les développeurs qui préfèrent travailler avec, par exemple, C#, Java et Python. Voilà pourquoi nous avons urgemment besoin de ce module. La structure syntaxique de PowerShell ne se prête pas à celle du générateur du kit de développement logiciel .Net/Java/Python (voir pourquoi nous avons un [rédacteur Vipr personnalisé](#why-a-custom-writer)).
+
+## Présentation de Vipr
+- L’architecture est construite autour du projet de recherche Microsoft Vipr.
+- Vipr généralise le concept de transformation d’informations d’une syntaxe à une autre.
+- Vipr est comme un analyseur de texte modulaire spécialement adapté aux définitions des services dans le style d’OData.
+- L’exécutable accepte un assembly lecteur et un assembly rédacteur.
+    - Le lecteur peut analyser le fichier texte d’entrée et le transformer en une représentation (générique) intermédiaire.
+    - Le rédacteur reçoit cette représentation intermédiaire et renvoie une liste d’objets fichiers, par exemple des paires (chaîne, chemin d’accès).
+        - Vipr écrit ensuite ces fichiers de la structure du dossier donné au dossier de sortie.
+
+## Pourquoi utiliser un rédacteur personnalisé ?
+Il n’existe aucun rédacteur PowerShell pour Vipr. De même, le rédacteur du kit de développement logiciel Graph pour .Net/Java/Python ne se prête pas facilement à la syntaxe, le comportement ou les bonnes habitudes de PowerShell.
+
+## Pourquoi ne pas utiliser OpenAPI et Swagger ?
+C’est une possibilité, mais cela nécessiterait une transformation supplémentaire du schéma OData de Graph vers le format OpenAPI. À chaque transformation, il y a un risque de perte d’informations précieuses dans le module PowerShell généré.