Bonjour,

Je n'ai pas pris l'habitude de msgcat les po ...
Je me rends pas bien compte de son importance (ni très bien de son rôle)
Je veux bien vos avis et explications (voire un exemple s'il est nécessaire)
Merci,
amicalement,
bubu

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonjour,

Le 14/01/2022 à 22:35, bubub@no-log.org a écrit :

Bonjour,

Je n'ai pas pris l'habitude de msgcat les po ...
Je me rends pas bien compte de son importance (ni très bien de son rôle)
Je veux bien vos avis et explications (voire un exemple s'il est nécessaire)
Merci,
amicalement,
bubu

Je pense qu'il a un rôle "historique" : cela renvoie au temps où les terminaux affichaient un nombre limité de colonnes avec des ligne de 72,
73, 76 voire 80 colonnes/caractères. Cela apparaît encore dans le
réglage par défaut de certains outils : la fenêtre de courrier que
j'utilise pour ce message (Thunderbird) coupe les lignes automatiquement
à 73 caractères et, par exemple dans les annonces de mise à jour de
version de Debian, pour conserver une mise en page de tableau, il ne
faut pas que les lignes dépassent 73 caractères sinon un saut de ligne
est introduite et perturbe la mise en page.
Et quand le bureau est encombré par un terminal, une fenêtre IRC, deux
ou trois fenêtres de navigateurs, la fenêtre de l'éditeur de fichier,
doit garder une largeur raisonnable quelque soit la taille de l'écran.
D'autre part, certains programmes étendent les fenêtres à l'infini quand
il n'y a pas de saut de ligne et il faut faire défiler la fenêtre pour
voir l'extrémité de la ligne (et c'est assez pénible...) ou alors
coupent les lignes à la bordure de la fenêtre au milieu des mots (ça
aussi c'est pénible).

Pour les po, c'est surtout une facilité pour les corrections : il est
plus facile de repérer les erreurs dans un fichier diff si les lignes comparées ont un nombre limité de caractères : l'exemple du fichier
xz-utils récemment traduit, avec des chaînes de plusieurs centaines de caractères, en est un bon exemple.
Le responsable des manpages vérifie et corrige les lignes non
"calibrées" à 80 caractères, je suppose parce que le "parser" qui
transforme les po lors de la transformation de format pour la
construction du paquet et des pages html des manpages doit mieux
"digérer" les entrées à 80 caractères.

Le logiciel Lokalize d'aide à la traduction permet de composer les
textesen continue puis il utilise msgcat (ou un équivalent) pour couper
les ligne à l'enregistrement. Il est parfois dangereux car il coupe
aussi parfois des lignes longues de l'original anglais

Bien sûr l'utilisation de traitement de texte comme LibreOffice permet
de s'affranchir de ces problèmes, mais ce n'est sûrement pas le meilleur outil pour éditer des fichier au format texte brut ou pour écrire des
bouts de code avec des indentations qui ont un sens pour l'interpréteur
par exemple.

Il y a sans doute d'autres raisons pour l'utilisation de msgcat que
pourront t'apporter d'autres lecteurs de la liste.

Amicalement,
jipege

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le samedi 15 janvier 2022 à 01:02 +0100, Jean-Pierre Giraud a écrit :

Bonjour,

Le 14/01/2022 à 22:35, bubub@no-log.org a écrit :

Bonjour,

Je n'ai pas pris l'habitude de msgcat les po ...
Je me rends pas bien compte de son importance (ni très bien de son rôle)
Je veux bien vos avis et explications (voire un exemple s'il est nécessaire)
Merci,
amicalement,
bubu

Je pense qu'il a un rôle "historique" : cela renvoie au temps où les terminaux affichaient un nombre limité de colonnes avec des ligne de 72, 73, 76 voire 80 colonnes/caractères. Cela apparaît encore dans le
réglage par défaut de certains outils : la fenêtre de courrier que j'utilise pour ce message (Thunderbird) coupe les lignes automatiquement
à 73 caractères et, par exemple dans les annonces de mise à jour de version de Debian, pour conserver une mise en page de tableau, il ne
faut pas que les lignes dépassent 73 caractères sinon un saut de ligne
est introduite et perturbe la mise en page.
Et quand le bureau est encombré par un terminal, une fenêtre IRC, deux
ou trois fenêtres de navigateurs, la fenêtre de l'éditeur de fichier, doit garder une largeur raisonnable quelque soit la taille de l'écran. D'autre part, certains programmes étendent les fenêtres à l'infini quand il n'y a pas de saut de ligne et il faut faire défiler la fenêtre pour voir l'extrémité de la ligne (et c'est assez pénible...) ou alors
coupent les lignes à la bordure de la fenêtre au milieu des mots (ça aussi c'est pénible).

Pour les po, c'est surtout une facilité pour les corrections : il est
plus facile de repérer les erreurs dans un fichier diff si les lignes comparées ont un nombre limité de caractères : l'exemple du fichier xz-utils récemment traduit, avec des chaînes de plusieurs centaines de caractères, en est un bon exemple.
Le responsable des manpages vérifie et corrige les lignes non
"calibrées" à 80 caractères, je suppose parce que le "parser" qui transforme les po lors de la transformation de format pour la
construction du paquet et des pages html des manpages doit mieux
"digérer" les entrées à 80 caractères.

Le logiciel Lokalize d'aide à la traduction permet de composer les
textesen continue puis il utilise msgcat (ou un équivalent) pour couper
les ligne à l'enregistrement. Il est parfois dangereux car il coupe
aussi parfois des lignes longues de l'original anglais

Bien sûr l'utilisation de traitement de texte comme LibreOffice permet
de s'affranchir de ces problèmes, mais ce n'est sûrement pas le meilleur outil pour éditer des fichier au format texte brut ou pour écrire des bouts de code avec des indentations qui ont un sens pour l'interpréteur
par exemple.

Il y a sans doute d'autres raisons pour l'utilisation de msgcat que
pourront t'apporter d'autres lecteurs de la liste.

Amicalement,
jipege
Bonjour,

j'ai moi-aussi bien des difficultés à identifier quel outil utiliser pour un
format donné .
Merci à JiP pour ces rappels qui illustrent les différences entre un langage
formel de machine et nos langues naturelles qui ont évolué à travers les époques ,les régions ....et leur utilisation.
Nos grammaires "naturellement humaines" n'ont certainement pas les même critères
de validation et entraînent des conceptions différentes d'Intelligence Artificielle.
Si l'on prend un MOT pour entité lexicale, c'est dans LES dictionnaireS que l'on
va trouver ses versions conjuguées, accordées...et sa racine (le RADICAL) qui va être différent en anglais, allemand, latin....
Les techniques de "racinisation" (STEMMING in english) sont différentes selon
les langues.
Et pour une machine ?
Il faut bien trouver un ensemble de mots capable de qualifier un texte !!
Je sais que nos prépositions,articles et mots de liaison ( le , et, à, la....)
sont considérés comme des "mots vides" ( STOP WORDS in english ) lorsque l'on
veut détecter un sujet.
Les supprimer permet certainement de créer une liste de mots qui fait abstraction de la langue.

Doit-on les remplacer ? Certainement pas par des "sauts de lignes" .

Quels dictionnaireS pour l'ordi?

Quelles définitions du MOT et de la LIGNE pour nos machines?

En considèrant un texte comme un "sac de mots", je vais commencer l'année sans
LibreOffice, avec Vim....et vos éclairages.

Amicalement.

Bonjour,

j'ai moi-aussi bien des difficultés pour identifier quel outil utiliser pour un format donné .
Merci à JiP pour ces rappels qui illustrent les différences entre un langage formel de machine et nos langues naturelles qui ont évolué à travers les époques ,les régions ....et leur utilisation.

Nos grammaires "naturellement humaines" n'ont certainement pas les même critères de validation et entraînent des conceptions différentes d'Intelligence Artificielle.
Si l'on prend un MOT pour entité lexicale, c'est dans LES dictionnaireS que l'on va trouver ses versions conjuguées, accordées...et sa racine (le RADICAL)
qui va être différent en anglais, allemand, latin....
Les techniques de "racinisation" (STEMMING in english) sont différentes selon les langues.

Et pour une machine ?
Il faut bien trouver un ensemble de mots capable de qualifier un texte :"-)

Je sais que nos prépositions,articles et mots de liaison ( le , et, à, la....)
sont considérés comme des "mots vides" ( STOP WORDS in english ) lorsque l'on veut détecter un sujet.
Les supprimer permet certainement de créer une liste de mots qui fait abstraction de la langue.

Doit-on les remplacer ? Certainement pas par des "sauts de lignes" .

Quels dictionnaireS pour l'ordi?

Quelles définitions du MOT et de la LIGNE pour nos machines?

En considèrant un texte comme un "sac de mots", je vais commencer l'année sans
LibreOffice, avec Vim....et vos éclairages.

Amicalement.



-----BEGIN PGP SIGNATURE-----

iQJPBAABCgA5FiEErl9eUc9FdsspUlEe4HEr1yIeQ/MFAmHjy8sbHGRhbmllbC5t YWxnb3JuQGxhcG9zdGUubmV0AAoJEOBxK9ciHkPzOcoP/1zYaYeLBqT1jOogCUSc ysYJnT82Zts1p72nVsy7oeKs1gzI+tNsTd4+aNQFCMr4QxtfSqEkU7R/PgF7373d nhGAEhptQWtkhx7JbGgpuaC14JBqvKCaWEhp3kViwrUJwBdQZpDvm4x8oCYRI5PD aUsRnko7MgS0PF9LiV04ftixksXYWR5g7ZKEe1dIr4fmRvFUE9D2pepTXMpB4en7 qGIusGuJ5l7D/ZMhD6Cdjnk+MrVdWTRmxoY2MRBKlcia6xvMANOQkVzrJUz8SE9R xEaCLEu85gHXofWgs7oQZxdBwoxUe3pdXhEE56r7d2jdgCbvdJOCgpJuqvkakgX4 ZYW6Wnx+FcOjHRIkv7AAsSQwbz+BDfIBUC3vAjpW8bgL566qfLIgKVelZq6/ZBhh SCx4z7V2KTxVyOAc17bdauua75RPSd6+C4wtBdaBqjzDVbS34dV5sp91Jxawpdmb Cb/0fb2e9MiunuBL2X+4cDM+MMouLJ3c7zFmYqA0GLbf5ZM/aTormEY4sRCayYUA +sNBepw70yah4aI1Xit9rDJh3aD+NlVlQc7mmJk3uWDn5VyTKvZegh1eYvw4n8yq +40uYgq+x7gpvlwi8r5f2ZkQBXFA2vODgMwo5rOuTDNQJS1c0OYvBplDOaSC9nIq BSdvJz/Q9jnHaEPOwnZJ/q5h
=3pTw
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)