Je vais passer un coup sur la documentation i18n. Voici le plan prévu : 1 - Présentation - explication rapide du contexte et de l'API 2 - Tutoriaux 1 - Utilisation simple I18n (sans maven) : 1 Hello world traduit en 3-4 langues : une classe et 1 bundle 2 - Utilisation i18n librairie (maven) : utilisation des goals parser + gen 3 - Utilisation i18n appli finale (maven) : utilisation des goals parser + gen + bundle ; utilisation du DefaultInitializer 3 - Developpeurs - How-to extend Initializer Comme on a des tutos, j'aurais bien fait un module i18n-tutorials qui aurait 3 modules : - 1 module i18n-helloworld (tuto simple - pas d'utilisation du plugin i18n, juste la dépendance) - 1 module i18n-library (tuto librairie) - 1 module i18n-application (tuto appli finale) Ce module permettrait de conserver des exemples toujours à jour, et ce même si la doc a un peu de retard. Qu'est-ce que vous pensez du plan de la doc et de l'idée du module pour les tutos ? Jean
On Fri, 02 Apr 2010 10:02:06 +0200 Jean Couteau <couteau@codelutin.com> wrote:
Je vais passer un coup sur la documentation i18n. Voici le plan prévu :
1 - Présentation - explication rapide du contexte et de l'API
2 - Tutoriaux 1 - Utilisation simple I18n (sans maven) : 1 Hello world traduit en 3-4 langues : une classe et 1 bundle 2 - Utilisation i18n librairie (maven) : utilisation des goals parser + gen 3 - Utilisation i18n appli finale (maven) : utilisation des goals parser + gen + bundle ; utilisation du DefaultInitializer
3 - Developpeurs - How-to extend Initializer
j'ajouterais une section bonne pratique et j'en vois deux: - soit a la getext, le dev ecrit sont texte en anglais dans le code et d'autre peuvent faire la traduction lorsqu'il le souhaite - soit a la microsoft on met une cle dans le code et on traduit cette cle tout de suite une premiere fois dans le fichier dans sa langue (anglais?)
Comme on a des tutos, j'aurais bien fait un module i18n-tutorials qui aurait 3 modules : - 1 module i18n-helloworld (tuto simple - pas d'utilisation du plugin i18n, juste la dépendance) - 1 module i18n-library (tuto librairie) - 1 module i18n-application (tuto appli finale)
Ce module permettrait de conserver des exemples toujours à jour, et ce même si la doc a un peu de retard.
Je ne suis pas sur que ce soit bien, dans l'absolu sans doute, mais ca va alourdir le projet de facon deraisonnable je pense. (toujours mon probleme du nombre de modules, packages, classes, ... :)
Qu'est-ce que vous pensez ...
qu'il faut arreter le cross-post sur dev car maintenant tout le monde est automatiquement sur toutes les listes projets -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
Le Fri, 2 Apr 2010 12:07:31 +0200, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Fri, 02 Apr 2010 10:02:06 +0200 Jean Couteau <couteau@codelutin.com> wrote:
Je vais passer un coup sur la documentation i18n. Voici le plan prévu :
1 - Présentation - explication rapide du contexte et de l'API
2 - Tutoriaux 1 - Utilisation simple I18n (sans maven) : 1 Hello world traduit en 3-4 langues : une classe et 1 bundle 2 - Utilisation i18n librairie (maven) : utilisation des goals parser + gen 3 - Utilisation i18n appli finale (maven) : utilisation des goals parser + gen + bundle ; utilisation du DefaultInitializer
3 - Developpeurs - How-to extend Initializer
j'ajouterais une section bonne pratique et j'en vois deux: - soit a la getext, le dev ecrit sont texte en anglais dans le code et d'autre peuvent faire la traduction lorsqu'il le souhaite Oui mais il faut alors définir une langue par défaut à toujours utiliser de ce mode.
- soit a la microsoft on met une cle dans le code et on traduit cette cle tout de suite une premiere fois dans le fichier dans sa langue (anglais?) euh je ne suis pas d'accord! c'est pas du tout à la microsoft, je dirais plutôt à la java...
Dans tous les cas, les deux solutions ne sont pas satisfaisantes je trouve (malheureusement y'a pas trop solution...)
Comme on a des tutos, j'aurais bien fait un module i18n-tutorials qui aurait 3 modules : - 1 module i18n-helloworld (tuto simple - pas d'utilisation du plugin i18n, juste la dépendance) - 1 module i18n-library (tuto librairie) - 1 module i18n-application (tuto appli finale)
Ce module permettrait de conserver des exemples toujours à jour, et ce même si la doc a un peu de retard.
Je ne suis pas sur que ce soit bien, dans l'absolu sans doute, mais ca va alourdir le projet de facon deraisonnable je pense. (toujours mon probleme du nombre de modules, packages, classes, ... :)
Qu'est-ce que vous pensez ...
qu'il faut arreter le cross-post sur dev car maintenant tout le monde est automatiquement sur toutes les listes projets
-- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii _______________________________________________ I18n-devel mailing list I18n-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/i18n-devel
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le Fri, 2 Apr 2010 12:07:31 +0200, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Fri, 02 Apr 2010 10:02:06 +0200 Jean Couteau <couteau@codelutin.com> wrote:
Je vais passer un coup sur la documentation i18n. Voici le plan prévu :
1 - Présentation - explication rapide du contexte et de l'API
2 - Tutoriaux 1 - Utilisation simple I18n (sans maven) : 1 Hello world traduit en 3-4 langues : une classe et 1 bundle 2 - Utilisation i18n librairie (maven) : utilisation des goals parser + gen 3 - Utilisation i18n appli finale (maven) : utilisation des goals parser + gen + bundle ; utilisation du DefaultInitializer
3 - Developpeurs - How-to extend Initializer
j'ajouterais une section bonne pratique et j'en vois deux: - soit a la getext, le dev ecrit sont texte en anglais dans le code et d'autre peuvent faire la traduction lorsqu'il le souhaite - soit a la microsoft on met une cle dans le code et on traduit cette cle tout de suite une premiere fois dans le fichier dans sa langue (anglais?)
Comme on a des tutos, j'aurais bien fait un module i18n-tutorials qui aurait 3 modules : - 1 module i18n-helloworld (tuto simple - pas d'utilisation du plugin i18n, juste la dépendance) - 1 module i18n-library (tuto librairie) - 1 module i18n-application (tuto appli finale)
Ce module permettrait de conserver des exemples toujours à jour, et ce même si la doc a un peu de retard.
Je ne suis pas sur que ce soit bien, dans l'absolu sans doute, mais ca va alourdir le projet de facon deraisonnable je pense. (toujours mon probleme du nombre de modules, packages, classes, ... :)
Qu'est-ce que vous pensez ...
qu'il faut arreter le cross-post sur dev car maintenant tout le monde est automatiquement sur toutes les listes projets
bah ouai mais uniquement quand les listes fonctionnent :) Ce qui n'était pas le cas hier...
-- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii _______________________________________________ I18n-devel mailing list I18n-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/i18n-devel
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Benjamin POUSSIN wrote:
On Fri, 02 Apr 2010 10:02:06 +0200 Jean Couteau <couteau@codelutin.com> wrote:
Je vais passer un coup sur la documentation i18n. Voici le plan prévu :
1 - Présentation - explication rapide du contexte et de l'API
2 - Tutoriaux 1 - Utilisation simple I18n (sans maven) : 1 Hello world traduit en 3-4 langues : une classe et 1 bundle 2 - Utilisation i18n librairie (maven) : utilisation des goals parser + gen 3 - Utilisation i18n appli finale (maven) : utilisation des goals parser + gen + bundle ; utilisation du DefaultInitializer
3 - Developpeurs - How-to extend Initializer
j'ajouterais une section bonne pratique et j'en vois deux: - soit a la getext, le dev ecrit sont texte en anglais dans le code et d'autre peuvent faire la traduction lorsqu'il le souhaite - soit a la microsoft on met une cle dans le code et on traduit cette cle tout de suite une premiere fois dans le fichier dans sa langue (anglais?)
Pas con... je rajoute.
Comme on a des tutos, j'aurais bien fait un module i18n-tutorials qui aurait 3 modules : - 1 module i18n-helloworld (tuto simple - pas d'utilisation du plugin i18n, juste la dépendance) - 1 module i18n-library (tuto librairie) - 1 module i18n-application (tuto appli finale)
Ce module permettrait de conserver des exemples toujours à jour, et ce même si la doc a un peu de retard.
Je ne suis pas sur que ce soit bien, dans l'absolu sans doute, mais ca va alourdir le projet de facon deraisonnable je pense. (toujours mon probleme du nombre de modules, packages, classes, ... :)
Une autre possibilité, et je pense qu'on va partir dessus : 3 zips qui contiennent les sources des tutos. On aura pas la vérification au build, du coup on perd le fait d'avoir toujours les tutos à jour, mais c'est mieux que rien.
Qu'est-ce que vous pensez ...
qu'il faut arreter le cross-post sur dev car maintenant tout le monde est automatiquement sur toutes les listes projets
C'est vrai pardon ;)
participants (3)
-
Benjamin POUSSIN -
Jean Couteau -
Tony Chemit