CALC "N/D" en résultat de formule avec SI imbriqués

[sophi]

Donc dans ce cas, c'est effectivement un défaut de traduction qu'il faut pointer (= a bug :). Je vais donc modifier la traduction. Vous souhaitez pour la 3.5.x ou pour la 3.6 (s'il est nécessaire de communiquer sur d'éventuelles rétrocompatibilités ?)

À bientôt
Sophie

[Gerard_Fargeot]

Sophie Gautier wrote

Bonjour tout le monde,

...

Concernant l'erreur N/D traduite (comme les autres erreurs : VALUE! DIV/0
...etc, Sophie a raison de souligner qu'il est logique que celle-ci aussi
soit traduit.
Mais, car il y en a un, il n'est pas très logique dans ce cas que les
fonctions afférentes ne le soit pas - NA() - ou partiellement - ESTNA()
-.

J'écris =NA() et j'obtiens N/D.

Donc dans ce cas, c'est effectivement un défaut de traduction qu'il faut
pointer (= a bug :). Je vais donc modifier la traduction. Vous souhaitez
pour la 3.5.x ou pour la 3.6 (s'il est nécessaire de communiquer sur
d'éventuelles rétrocompatibilités ?)

À bientôt
Sophie

Sauf erreur de ma part, je ne pense pas qu'il y ai un problème de
rétrocompatibilité vu que les formules sont stockés en Anglais et non dans
la locale.
Mais je n'ai pas connu de cas de changement de nom de fonction (excepté
LIEN_HYPERTEXTE qui est devenu LIEN.HYPERTEXTE mais je ne me souviens pas si
cela avait posé problème).

Si un ancien (je n'ai pas dit vieux ) pouvait confirmer.

Sinon, il n'y a pas urgence. Si cela devait poser problème, il serait sans
doute souhaitable de ne faire la modif que pour une version majeure.

Gérard

[sophi]

Sophie Gautier wrote

Bonjour tout le monde,

...

Concernant l'erreur N/D traduite (comme les autres erreurs : VALUE! DIV/0
...etc, Sophie a raison de souligner qu'il est logique que celle-ci aussi
soit traduit.
Mais, car il y en a un, il n'est pas très logique dans ce cas que les
fonctions afférentes ne le soit pas - NA() - ou partiellement - ESTNA()
-.

J'écris =NA() et j'obtiens N/D.

Donc dans ce cas, c'est effectivement un défaut de traduction qu'il faut
pointer (= a bug :). Je vais donc modifier la traduction. Vous souhaitez
pour la 3.5.x ou pour la 3.6 (s'il est nécessaire de communiquer sur
d'éventuelles rétrocompatibilités ?)

À bientôt
Sophie

Sauf erreur de ma part, je ne pense pas qu'il y ai un problème de
rétrocompatibilité vu que les formules sont stockés en Anglais et non dans
la locale.

Oui, c'est effectivement ce sur quoi je compte à chaque fois que je fais une modif.

Mais je n'ai pas connu de cas de changement de nom de fonction (excepté
LIEN_HYPERTEXTE qui est devenu LIEN.HYPERTEXTE mais je ne me souviens pas si
cela avait posé problème).

Je n'ai pas souvenir non plus, c'est pour respecter la syntaxe générale que j'ai fait cette modification.

Si un ancien (je n'ai pas dit vieux ) pouvait confirmer.

je dois être la vieille qui veille sur ces modifs

Sinon, il n'y a pas urgence. Si cela devait poser problème, il serait sans
doute souhaitable de ne faire la modif que pour une version majeure

Ce que je fais en général (et pour cette fois également avec la 3.5) c'est que je modifie pour une version mineure et j'attends de voir les retours pour les versions majeures. Actuellemnt, il y a plusieurs noms de fonctions que je n'ai pas traduit pour la 3.5 parceque je n'en voyais pas l'utilité, on verra bien si cela dérange

Bonne soirée
Sophie

[Rafael_Laville]

Ce n'est pas un contournement, c'est la gestion normale d'une valeur d'erreur.
Ceci étant, combien de gens connaissaient (et connaissent) la signification de #N/A et combien connnaitront celle de #N/D ? Pour eux, ce n'est ni du français, ni de l'anglais, c'est de l'informatique.

[Jean-Luc_Coulon_f5ib]

Bonsoir,
Je réponds directement sur Nabble parce que la réponse via mail a tendance
à s'égarer une fois sur deux.

J'avais donc dit :

- Quel la solution de Pierre-Yvs me convient. Merci à lui.

- En ce qui concerne le formatage our éviter que la valeur "FAUX" ne
s'affiche, je ne suis pas certain que cela me convienne : en numérique, les
valeurs nulles sont alors également masquée. Alors que 0.00 est
numérique...

- Que, évidemment, les matrices ne sont pas nécessaires ICI. Mais ma
question ne portait pas sur le fait que ce soit judicieux ou pas... des
questions à ce sujet viendront peut-être... plus tard. J'ai juste posté un
bout de feuille qui pose le problème. Le projet est bien plus important, ce
sont des tableaux de coordonnées avec lesquels je fais des tracés dans draw
en BASIC (ou python... mais bon, l'API python n'est pas très bien
documenté). Je fais, sur ces courbes, des transformations et des changements
de repère et là, appliquer une matrice de transformation ou inverser une
matrice est immédiat sous calc alors que c'est looooong sous Basic (ça rame
en fait).

- La solution de Sandy-Pascal ne fonctionne pas...

- Pour ce qui est #N/A -> #N/D et la fonction NA(), ce qui serait bon, c'est
que l'évolution de la doc suive celle du logiciel.

Merci à tous, bonne soirée/nuit

Jean-Luc

[christianwtd]

...

Mais je n'ai pas connu de cas de changement de nom de fonction (excepté
LIEN_HYPERTEXTE qui est devenu LIEN.HYPERTEXTE mais je ne me souviens pas si
cela avait posé problème).

Si un ancien (je n'ai pas dit vieux ) pouvait confirmer.

Bonsoir,

Un petit vieux confirme
Tu peux ajouter GETPIVOTDATA qui est devenu EXTRAIRE.DONNEES.PILOTE
(non traduit dans les premières versions)

..

Gérard

Bon surf,
Christian

[sophi]

Bonsoir,

Bonsoir,

Le code en question est l’équivalent de l’anglais #NA (qu’on avait
avec les versions 1 et 2 d’OpenOffice et qui a - en locale Fr - été
remplacé par #ND.

Le message associé est "Erreur : Valeur non disponible".

J'ignorais que #N/A était un code anglais. Pour moi, il signifiait "non
applicable".

Ce qui est génant c'est d'avoir un message (valeur non disponible) en
français pour un code en anglais (A est pour Available), c'est pas
très cohérent... Les codes d'erreur étaient pendant un temps à moitié
traduits, ils le sont tous maintenant (normalement

Ceci étant, le changement peut être gênant pour certains. Par exemple,
un programme traite un fichier csv susceptible de contenir des valeurs
d'erreur. Sachant cela, on traite spécifiquement les données valant
#N/A. Mais comme le code d'erreur a changé, la donnée #N/D sera
considérée comme valide et le programme plantera. Ce qui peut conduire à
d'ennuyeuses conséquences.

Donc il vaut mieux garder les bugs parce qu'on est habitué à les
contourner ?

À bientôt
Sophie
--

Ce n'est pas un contournement, c'est la gestion normale d'une valeur
d'erreur.
Ceci étant, combien de gens connaissaient (et connaissent) la
signification de #N/A et combien connnaitront celle de #N/D ? Pour eux,
ce n'est ni du français, ni de l'anglais, c'est de l'informatique.

Du contributeur que je suis :
. soit on se positionne du côté l10n et on apporte une solution
. soit on se positionne au niveau dev et on apporte une solution
. soit c'est ux/utilisateur et idem
mais là, informatique ça veut dire quoi ?

À bientôt
Sophie

[sophi]

ah oui, la toute première parce que ce n'était pas indiqué dans le cws qu'il y avait de la localisation, donc réaction un peu tardive
Mais je ne pense pas que cela ai posé problème de rétrocompatibilité, si?
À bientôt
Sophie

[christianwtd]

Aucun problème à ma connaissance.
Je viens de retrouver. C'était dans v2.3
Ça nous rajeunit pas, tout ça

Bon surf,
Christian

[Rafael_Laville]

J'ignorais que #N/A était un code anglais. Pour moi, il signifiait "non applicable".

C’est assez facile à voir.
Dans une cellule, mettez ce qui suit :
=NA()

Cette fonction force justement cette valeur d’erreur.
Et on obtient (au moins avec ma version)... #N/D

Ça ne dit rien sur la signification de A ni de D.

Ceci étant, le changement peut être gênant pour certains. Par
exemple, un programme traite un fichier csv susceptible de contenir
des valeurs d'erreur. Sachant cela, on traite spécifiquement les
données valant #N/A. Mais comme le code d'erreur a changé, la
donnée #N/D sera considérée comme valide et le programme plantera.
Ce qui peut conduire à d'ennuyeuses conséquences.

Si on a ces fâcheuses conséquences, c’est qu’on n’a pas programmé le
truc normalement.

Réponse simpliste. Voilà une explication plus détaillée. Mon client m'envoie un fichier CSV contenant des valeurs d'erreur. Selon les cas, je peux rejeter (entièrement ou partiellement) la ligne du fichier ou mettre à jour ma base de données avec un traitement spécifique (plus ou moins complexe) pour ces valeurs d'erreur.

La conséquence fâcheuse, c'est d'accepter comme valide une valeur qui ne l'est pas. Mais comme le programme ne peut pas le savoir, il faudra réparer les conséquences dans la base (activité couteuse et chronophage).

Par ailleurs, je ne crois pas obtenir de mon client qu'il modifie ses formules.

[Rafael_Laville]

Ça veut dire une langue aussi étrangère que les hiéroglyphes ou le cunéiforme.
Pour la plupart des gens, #N/D ou Err 987, c'est du pareil au même.

Mais le problème de fond n'est pas là. C'est qu'un comportement de base du tableur a changé. Le résultat d'une même formule avec les mêmes données en entrée n'est plus le même.
Et ici, on n'a pas corrigé de bug.

[Jacek1]

Bonjour,

Et comment ce problème se positionne dans le contexte d'interopérabilité avec autres suites bureautiques?
Quid d'échange de fichiers dans une entreprise multinational ou se côtoient les installations en anglais avec ceux en français?
Faut-il passer vers LuxO?

Bàv

Jacek

-----Message d'origine-----

[sophi]

Bonjour,

Et comment ce problème se positionne dans le contexte d'interopérabilité avec autres suites bureautiques?
Quid d'échange de fichiers dans une entreprise multinational ou se côtoient les installations en anglais avec ceux en français?
Faut-il passer vers LuxO?

Bàv

Jacek

-----Message d'origine-----
De : Rafael Laville [mailto:rafael.laville@live.fr]
Envoyé : jeudi 2 février 2012 22:52
À : users@fr.libreoffice.org
Objet : Re: [fr-users] CALC "N/D" en résultat de formule avec SI imbriqués

Bonsoir,

Bonsoir,

Le code en question est l’équivalent de l’anglais #NA (qu’on avait
avec les versions 1 et 2 d’OpenOffice et qui a - en locale Fr -
été remplacé par #ND.

Le message associé est "Erreur : Valeur non disponible".

J'ignorais que #N/A était un code anglais. Pour moi, il signifiait
"non applicable".

Ce qui est génant c'est d'avoir un message (valeur non disponible)
en français pour un code en anglais (A est pour Available), c'est
pas très cohérent... Les codes d'erreur étaient pendant un temps à
moitié traduits, ils le sont tous maintenant (normalement

Ceci étant, le changement peut être gênant pour certains. Par
exemple, un programme traite un fichier csv susceptible de contenir
des valeurs d'erreur. Sachant cela, on traite spécifiquement les
données valant #N/A. Mais comme le code d'erreur a changé, la
donnée #N/D sera considérée comme valide et le programme plantera.
Ce qui peut conduire à d'ennuyeuses conséquences.

Donc il vaut mieux garder les bugs parce qu'on est habitué à les
contourner ?

À bientôt
Sophie
--

Ce n'est pas un contournement, c'est la gestion normale d'une valeur
d'erreur.
Ceci étant, combien de gens connaissaient (et connaissent) la
signification de #N/A et combien connnaitront celle de #N/D ? Pour
eux, ce n'est ni du français, ni de l'anglais, c'est de l'informatique.

Du contributeur que je suis :
. soit on se positionne du côté l10n et on apporte une solution . soit
on se positionne au niveau dev et on apporte une solution . soit c'est
ux/utilisateur et idem mais là, informatique ça veut dire quoi ?

Ça veut dire une langue aussi étrangère que les hiéroglyphes ou le cunéiforme.
Pour la plupart des gens, #N/D ou Err 987, c'est du pareil au même.

hum, en effet, c'est plutôt de l'acquis

Mais le problème de fond n'est pas là. C'est qu'un comportement de base du tableur a changé. Le résultat d'une même formule avec les mêmes données en entrée n'est plus le même.
Et ici, on n'a pas corrigé de bug.

Ce n'est que de l'affichage, le traitement reste le même.

À bientôt
Sophie

[Jean-Luc_Coulon_f5ib]

Si on regarde le message dans la barre d’état :
- Avec une localisation anglaise : Error: Value not available
on peut donc supposer que le N est pour Not et le A pour Available, ce
qui donne N/A (ou NA)
- Avec une localisation française : Erreur : valeur non disponible
on peut donc penser que le N est pour Non et le D pour disponible, ce
qui donne N/D (ou ND)

Donc, du point de vue strict de la traduction N/D est bien la traduction
de N/A de la version anglaise.

Maintenant, si N/A ne signifie pas "not available", le problème se
trouve ailleurs…

Jean-Luc

[Rafael_Laville]

Je découvre qu'un message s'affiche dans la barre d'état pour les valeurs d'erreur.
Mais mon souci d'origine portait sur un fichier à traiter provenant d'une source extérieure et contenant des valeurs d'erreur.

[Jean-Luc_Coulon_f5ib]

[... ]

Je découvre qu'un message s'affiche dans la barre d'état pour les
valeurs d'erreur.

Sur une page, il faut tout lire

Mais mon souci d'origine portait sur un fichier à traiter provenant
d'une source extérieure et contenant des valeurs d'erreur.

Comme je le disais précédemment, si les valeurs d‘erreurs sont du texte,
ET QU’ELLE PEUVENT SE TROUVER DANS DES LANGUES DIFFÉRENTES, on ne peut
pas faire l’économie soit d’une table de consultation, soit d’un test
sur plusieurs valeurs...

si ((valeur = #N/A) ou (valeur = #N/D)) alors (erreur quelque_chose)

J-L

[Rafael_Laville]

Il n'était pas question d'une langue quelconque, il était question d'un code, à priori abstrait, donc non susceptible d'être traduit.
De plus, la valeur #N/D n'existait pas. Il était donc impossible de faire ce que tu dis.

[Jean-Luc_Coulon_f5ib]

Il faut un peu préciser, si on ne connaît pas le code en question, ni le
format du fichier...

Quel code ?

J-L

[Rafael_Laville]

Comme je l'ai indiqué dans un message précédent, il s'agit du code #N/A qui est devenu très discrètement #N/D.