Non. Lui, il veut un truc simple. Il ne sait d'ailleurs peut-être même pas qu'on sait faire les traductions de paquets.
Mmmh, tu as déjà parlé à des packagers ? Parce que je pense que tu te trompes en supposant que le packager va gérer lui-même les traductions dans les langues qu'il pratique (ça conduira de toute manière à des traductions approximatives, peu étant vraiment bilingues, encore moins trilingues).
La traduction est en général gérée par des équipes dédiées. Ca permet d'avoir une homogénéité dans les traductions (et même ainsi, c'est parfois peu satisfaisant).
Je vais prendre un exemple bête dans mon cas : si je fais un patch pour PostgreSQL qui demande une traduction, je ne vais pas la faire moi-même, y compris en français. Quelqu'un s'en occupe globalement et c'est bien mieux ainsi.
Accessoirement, ton fichier de méta-données avec toutes tes traductions dedans va vite devenir insupportable. Attends d'avoir du japonais et des gens qui l'éditent n'importe comment et qui vont te commiter un fichier complètement foireux.
Prenez un Windows, et regardez.
Difficile d'avoir une discussion argumentée quand tu sautes du coq à l'âne. Windows est traduit parce qu'un paquet de pognon est mis là-dedans.
Les distributions sont partiellement traduites parce que c'est un travail chiant, peu valorisant et que la majorité des gens qui le font ne sont pas payés pour le faire. Malgré toute leur bonne volonté, ils font ce qu'ils peuvent.
Accessoirement, les distributions Linux vont trop vite pour que les traductions suivent et on ne bloquera jamais une release parce que la traduction française n'est pas finie. Je suis assez sûr que chez MS, ils planifient la chose pour que le produit sorte dans une langue majeure avec *tout* traduit et plein de séances de relecture.
Une traduction homogène de qualité est un boulot titanesque (et je parle en connaissance de cause, j'avais repris les 6000-8000 clés de traduction d'un logiciel complètement histoire que tout soit homogène et cohérent - et 6000-8000, ce n'est pas bien gros quand on y pense).
L'utilisateur anglophobe sera totalement perdu. C'est ce genre de problème auxquels il faut faire attention.
Et tu penses que personne n'y a pensé avant toi ? Le manque de traduction n'a pas grand chose à voir avec une difficulté technique. C'est juste un manque de ressources dédiées à cela dans la durée.
Et espérer le résoudre en répartissant la traduction sur les packagers, ça donnera un truc aussi bien que les systèmes de traduction distribués où chacun traduit une chaîne en passant : rien de bien cohérent.
Setup sera un peu plus hackish, mais fera la même chose. En effet, on peut définir l'Installation-Root d'un paquet. Il suffit, quand on installe les paquets, de les installer dans /tmp/teporarytree. Une fois que tout est installé et testé (les postinst() des paquets peuvent servir à vérifier, ainsi que les || exit 1 dans le packagebuild), on copie simplement ce dossier dans /, et c'est fait.
Tu as bien en tête que la copie de fichiers n'est pas atomique ? Et qu'il ne va pas suffire de copier ? Il va aussi falloir supprimer les fichiers qui ne sont plus nécessaires, remonter d'éventuels conflits sur des fichiers de configuration existants suite à modification du fichier du paquet... Que se passe t-il avec ton système si le disque / est full pendant la copie ?
Je m'intéresse assez peu au sujet donc je n'ai aucune idée de comment rpm et dpkg ont réglé ces problèmes (et s'ils l'ont fait complètement d'ailleurs) mais tu n'as pas l'air d'en avoir plus et c'est inquiétant.
Si ça pète dans certains cas et que je me retrouve avec une installation cassée que je dois refaire, je vais vraiment être super content d'avoir gagné 2 secondes chaque mois quand je rajoute un paquet.
A mon avis, il faut vraiment que tu te poses et que tu réfléchisses à ce que veulent vraiment les gens. Tu verras que leur priorité n°1 sur un gestionnaire de packages est d'avoir un truc à toute épreuve.
Les gens ont grogné sur yum quand la lenteur était vraiment insupportable. Depuis que c'est acceptable sans être mirifique, les gens ne se plaignent plus trop.
Que tu attaques en réfléchissant à la performance et que tu en fasses une préoccupation majeure, pourquoi pas, il va bien falloir que tu te différencies. Mais sans avoir la vision globale de comment tu vas régler le problème du "rock solid", tu risques quand même fort d'arriver dans le mur à la fin.
Après, tu fais bien ce que tu veux. C'était juste un éclairage différent en passant sur ta démarche.
[^] # Re: De la facilité avec laquelle un paquet Setup est créé
Posté par Guillaume Smet (site web personnel) . En réponse au journal Sortie de Setup 0.1-alpha0. Évalué à 10.
Mmmh, tu as déjà parlé à des packagers ? Parce que je pense que tu te trompes en supposant que le packager va gérer lui-même les traductions dans les langues qu'il pratique (ça conduira de toute manière à des traductions approximatives, peu étant vraiment bilingues, encore moins trilingues).
La traduction est en général gérée par des équipes dédiées. Ca permet d'avoir une homogénéité dans les traductions (et même ainsi, c'est parfois peu satisfaisant).
Je vais prendre un exemple bête dans mon cas : si je fais un patch pour PostgreSQL qui demande une traduction, je ne vais pas la faire moi-même, y compris en français. Quelqu'un s'en occupe globalement et c'est bien mieux ainsi.
Accessoirement, ton fichier de méta-données avec toutes tes traductions dedans va vite devenir insupportable. Attends d'avoir du japonais et des gens qui l'éditent n'importe comment et qui vont te commiter un fichier complètement foireux.
Prenez un Windows, et regardez.
Difficile d'avoir une discussion argumentée quand tu sautes du coq à l'âne. Windows est traduit parce qu'un paquet de pognon est mis là-dedans.
Les distributions sont partiellement traduites parce que c'est un travail chiant, peu valorisant et que la majorité des gens qui le font ne sont pas payés pour le faire. Malgré toute leur bonne volonté, ils font ce qu'ils peuvent.
Accessoirement, les distributions Linux vont trop vite pour que les traductions suivent et on ne bloquera jamais une release parce que la traduction française n'est pas finie. Je suis assez sûr que chez MS, ils planifient la chose pour que le produit sorte dans une langue majeure avec *tout* traduit et plein de séances de relecture.
Une traduction homogène de qualité est un boulot titanesque (et je parle en connaissance de cause, j'avais repris les 6000-8000 clés de traduction d'un logiciel complètement histoire que tout soit homogène et cohérent - et 6000-8000, ce n'est pas bien gros quand on y pense).
L'utilisateur anglophobe sera totalement perdu. C'est ce genre de problème auxquels il faut faire attention.
Et tu penses que personne n'y a pensé avant toi ? Le manque de traduction n'a pas grand chose à voir avec une difficulté technique. C'est juste un manque de ressources dédiées à cela dans la durée.
Et espérer le résoudre en répartissant la traduction sur les packagers, ça donnera un truc aussi bien que les systèmes de traduction distribués où chacun traduit une chaîne en passant : rien de bien cohérent.
Setup sera un peu plus hackish, mais fera la même chose. En effet, on peut définir l'Installation-Root d'un paquet. Il suffit, quand on installe les paquets, de les installer dans /tmp/teporarytree. Une fois que tout est installé et testé (les postinst() des paquets peuvent servir à vérifier, ainsi que les || exit 1 dans le packagebuild), on copie simplement ce dossier dans /, et c'est fait.
Tu as bien en tête que la copie de fichiers n'est pas atomique ? Et qu'il ne va pas suffire de copier ? Il va aussi falloir supprimer les fichiers qui ne sont plus nécessaires, remonter d'éventuels conflits sur des fichiers de configuration existants suite à modification du fichier du paquet... Que se passe t-il avec ton système si le disque / est full pendant la copie ?
Je m'intéresse assez peu au sujet donc je n'ai aucune idée de comment rpm et dpkg ont réglé ces problèmes (et s'ils l'ont fait complètement d'ailleurs) mais tu n'as pas l'air d'en avoir plus et c'est inquiétant.
Si ça pète dans certains cas et que je me retrouve avec une installation cassée que je dois refaire, je vais vraiment être super content d'avoir gagné 2 secondes chaque mois quand je rajoute un paquet.
A mon avis, il faut vraiment que tu te poses et que tu réfléchisses à ce que veulent vraiment les gens. Tu verras que leur priorité n°1 sur un gestionnaire de packages est d'avoir un truc à toute épreuve.
Les gens ont grogné sur yum quand la lenteur était vraiment insupportable. Depuis que c'est acceptable sans être mirifique, les gens ne se plaignent plus trop.
Que tu attaques en réfléchissant à la performance et que tu en fasses une préoccupation majeure, pourquoi pas, il va bien falloir que tu te différencies. Mais sans avoir la vision globale de comment tu vas régler le problème du "rock solid", tu risques quand même fort d'arriver dans le mur à la fin.
Après, tu fais bien ce que tu veux. C'était juste un éclairage différent en passant sur ta démarche.