Non. L'espace reste un espace pour le parser, ca me semble logique.
-- Jean - JMST Belgium
Jean
<script> var u0438u043E = new Object() u0438u043E.u0438u043E='u0421u0414 u041Cu0414u042Fu0421u041Du0415' alert(u0438u043E.u0438u043E) </script>
... et ça ne fonctionne qu'avec des séquences u pas avec des séquences x, ce qui me semble logique puisque les traitements internes du moteur de script sont Unicode.
Sur ce ...
Amicalement,
-- Jean - JMST Belgium
<script>
var u0438u043E = new Object()
u0438u043E.u0438u043E='u0421u0414 u041Cu0414u042Fu0421u041Du0415'
alert(u0438u043E.u0438u043E)
</script>
... et ça ne fonctionne qu'avec des séquences u pas avec des séquences
x, ce qui me semble logique puisque les traitements internes du moteur
de script sont Unicode.
<script> var u0438u043E = new Object() u0438u043E.u0438u043E='u0421u0414 u041Cu0414u042Fu0421u041Du0415' alert(u0438u043E.u0438u043E) </script>
... et ça ne fonctionne qu'avec des séquences u pas avec des séquences x, ce qui me semble logique puisque les traitements internes du moteur de script sont Unicode.
Sur ce ...
Amicalement,
-- Jean - JMST Belgium
Jacques Barathon [MS]
"Jean" wrote in message news: <...>
J'avais commencé un projet de "traduction" du language PowerShell dans ma langue maternelle. Essentielement traduction des noms de cmdlet par alias et modification de fichiers psxml. Je crois que la seule chose qui manquait c'était quelque chose de simple pour "traduire" le nom des parmètres (ce qui reviendrait a étendre les capacités de Set-Alias).
Bref, ça permettrait au final de se retrouver avec un language informatique "parlant" sa langue maternelle (et pourquoi pas de pouvoir passer d'une langue à l'autre).
Ce qui à mon avis ouvre plus de portes que ça n'en ferme :-)
Projet intéressant. La contrainte de traduction des paramètres est un obstacle difficile. Il existe peut-être une solution permettant d'ajouter une sorte de "Script Parameter", de la même façon qu'on peut ajouter des Script Properties ou des Script Methods à un objet. Mais j'ai comme un doute. Tu pourrais poser la question sur le forum US dédié à PowerShell.
J'admets ... c'est futuriste :-)
Oh, pas tant que ça :-). Le VBA d'Office a depuis longtemps exploré cette voie de la localisation du langage. Personnellement j'y trouve plus de contraintes que d'avantages, notamment par la difficulté à porter un script d'une plateforme à l'autre si les langues différent. Evidemment, il y a un avantage important dans le contexte de l'utilisation d'Office pour l'utilisateur qui peut écrire des instructions dans sa propre langue. Mais l'avantage est moins marqué dans le contexte de PowerShell qui est plutôt destiné à des utilisateurs avancés voire des administrateurs de parc, pour lesquels écrire "prendre-élément" à la place de "get-item" n'apportera pas suffisamment par rapport à la perte de portabilité.
Jacques
"Jean" <repondre@groupe.svp> wrote in message
news:mn.bd977d73f93f97d3.56820@windows...
<...>
J'avais commencé un projet de "traduction" du language PowerShell dans ma
langue maternelle.
Essentielement traduction des noms de cmdlet par alias et modification de
fichiers psxml.
Je crois que la seule chose qui manquait c'était quelque chose de simple
pour "traduire" le nom des parmètres (ce qui reviendrait a étendre les
capacités de Set-Alias).
Bref, ça permettrait au final de se retrouver avec un language
informatique "parlant" sa langue maternelle (et pourquoi pas de pouvoir
passer d'une langue à l'autre).
Ce qui à mon avis ouvre plus de portes que ça n'en ferme :-)
Projet intéressant. La contrainte de traduction des paramètres est un
obstacle difficile. Il existe peut-être une solution permettant d'ajouter
une sorte de "Script Parameter", de la même façon qu'on peut ajouter des
Script Properties ou des Script Methods à un objet. Mais j'ai comme un
doute. Tu pourrais poser la question sur le forum US dédié à PowerShell.
J'admets ... c'est futuriste :-)
Oh, pas tant que ça :-). Le VBA d'Office a depuis longtemps exploré cette
voie de la localisation du langage. Personnellement j'y trouve plus de
contraintes que d'avantages, notamment par la difficulté à porter un script
d'une plateforme à l'autre si les langues différent. Evidemment, il y a un
avantage important dans le contexte de l'utilisation d'Office pour
l'utilisateur qui peut écrire des instructions dans sa propre langue. Mais
l'avantage est moins marqué dans le contexte de PowerShell qui est plutôt
destiné à des utilisateurs avancés voire des administrateurs de parc, pour
lesquels écrire "prendre-élément" à la place de "get-item" n'apportera pas
suffisamment par rapport à la perte de portabilité.
J'avais commencé un projet de "traduction" du language PowerShell dans ma langue maternelle. Essentielement traduction des noms de cmdlet par alias et modification de fichiers psxml. Je crois que la seule chose qui manquait c'était quelque chose de simple pour "traduire" le nom des parmètres (ce qui reviendrait a étendre les capacités de Set-Alias).
Bref, ça permettrait au final de se retrouver avec un language informatique "parlant" sa langue maternelle (et pourquoi pas de pouvoir passer d'une langue à l'autre).
Ce qui à mon avis ouvre plus de portes que ça n'en ferme :-)
Projet intéressant. La contrainte de traduction des paramètres est un obstacle difficile. Il existe peut-être une solution permettant d'ajouter une sorte de "Script Parameter", de la même façon qu'on peut ajouter des Script Properties ou des Script Methods à un objet. Mais j'ai comme un doute. Tu pourrais poser la question sur le forum US dédié à PowerShell.
J'admets ... c'est futuriste :-)
Oh, pas tant que ça :-). Le VBA d'Office a depuis longtemps exploré cette voie de la localisation du langage. Personnellement j'y trouve plus de contraintes que d'avantages, notamment par la difficulté à porter un script d'une plateforme à l'autre si les langues différent. Evidemment, il y a un avantage important dans le contexte de l'utilisation d'Office pour l'utilisateur qui peut écrire des instructions dans sa propre langue. Mais l'avantage est moins marqué dans le contexte de PowerShell qui est plutôt destiné à des utilisateurs avancés voire des administrateurs de parc, pour lesquels écrire "prendre-élément" à la place de "get-item" n'apportera pas suffisamment par rapport à la perte de portabilité.
Jacques
Michel Claveau
Jean, réponse globale :
1) la nuit a été profitable, je vois...
2) pour les caractères unicode, OK, avec la syntaxe uXXXX ; dont acte. Pour moi, j'avais essayé, avec un éditeur, en UTF-8, avec un omega majuscule, et ça ne marchait pas. En pratique, il faudrait un éditeur qui convertisse les caractères Unicode en uXXXX à l'enregistrement.
3) pour les accents dans les ActiveX. C'est comme avec COM. D'après mes expériences, ça peut marcher (la technique COM travaille en Unicode), mais ça dépend des (composants) logiciels, des deux côtés.
Par exemple, Paradox ne fait pas de distinction entre majuscules et minuscules, et ne gère pas les accents (dans COM).
Dans ce cas COM se débrouille pour faire la translation. En pratique, lors d'un appel, COM effectue deux appels : le premier, natif ; si ça échoue, COM effectue un second appel après avoir convertit en majuscules (sans accents).
J'étais tombé sur ça, lorsque j'ai développé la partie COM-dynamique de Ponx. Mais, j'avais été obligé de gérer un message de retour à COM, lors d'un appel qui échoue, pour qu'il effectue le second appel (translaté).
Ce n'est donc pas toujours automatique.
-- @-salutations
Michel Claveau
Jean, réponse globale :
1) la nuit a été profitable, je vois...
2) pour les caractères unicode, OK, avec la syntaxe uXXXX ; dont acte.
Pour moi, j'avais essayé, avec un éditeur, en UTF-8, avec un omega
majuscule, et ça ne marchait pas. En pratique, il faudrait un éditeur
qui convertisse les caractères Unicode en uXXXX à l'enregistrement.
3) pour les accents dans les ActiveX. C'est comme avec COM. D'après mes
expériences, ça peut marcher (la technique COM travaille en Unicode),
mais ça dépend des (composants) logiciels, des deux côtés.
Par exemple, Paradox ne fait pas de distinction entre majuscules et
minuscules, et ne gère pas les accents (dans COM).
Dans ce cas COM se débrouille pour faire la translation. En pratique,
lors d'un appel, COM effectue deux appels : le premier, natif ; si ça
échoue, COM effectue un second appel après avoir convertit en
majuscules (sans accents).
J'étais tombé sur ça, lorsque j'ai développé la partie COM-dynamique de
Ponx. Mais, j'avais été obligé de gérer un message de retour à COM,
lors d'un appel qui échoue, pour qu'il effectue le second appel
(translaté).
2) pour les caractères unicode, OK, avec la syntaxe uXXXX ; dont acte. Pour moi, j'avais essayé, avec un éditeur, en UTF-8, avec un omega majuscule, et ça ne marchait pas. En pratique, il faudrait un éditeur qui convertisse les caractères Unicode en uXXXX à l'enregistrement.
3) pour les accents dans les ActiveX. C'est comme avec COM. D'après mes expériences, ça peut marcher (la technique COM travaille en Unicode), mais ça dépend des (composants) logiciels, des deux côtés.
Par exemple, Paradox ne fait pas de distinction entre majuscules et minuscules, et ne gère pas les accents (dans COM).
Dans ce cas COM se débrouille pour faire la translation. En pratique, lors d'un appel, COM effectue deux appels : le premier, natif ; si ça échoue, COM effectue un second appel après avoir convertit en majuscules (sans accents).
J'étais tombé sur ça, lorsque j'ai développé la partie COM-dynamique de Ponx. Mais, j'avais été obligé de gérer un message de retour à COM, lors d'un appel qui échoue, pour qu'il effectue le second appel (translaté).
Ce n'est donc pas toujours automatique.
-- @-salutations
Michel Claveau
Michel Claveau
Re !
un language informatique "parlant" sa langue maternelle
Dans les années 1800 et des poussières, certains avaient poussé un projet de la même veine : le "BASICOIS".
A l'époque, ça n'avais pas été viable. Alors, que dire, lorsque, comme actuellement, on se fait incendier, sur la moitié des newsgroups américains, pour un banal message en français ?
Néanmoins, le principe me semble louable.
Toutefois, je serais curieux de voir ce que ça peut donner dans une langue en boustrophédon... mdr
-- @-salutations
Michel Claveau
Re !
un language informatique "parlant" sa langue maternelle
Dans les années 1800 et des poussières, certains avaient poussé un
projet de la même veine : le "BASICOIS".
A l'époque, ça n'avais pas été viable. Alors, que dire, lorsque, comme
actuellement, on se fait incendier, sur la moitié des newsgroups
américains, pour un banal message en français ?
Néanmoins, le principe me semble louable.
Toutefois, je serais curieux de voir ce que ça peut donner dans une
langue en boustrophédon... mdr
un language informatique "parlant" sa langue maternelle
Dans les années 1800 et des poussières, certains avaient poussé un projet de la même veine : le "BASICOIS".
A l'époque, ça n'avais pas été viable. Alors, que dire, lorsque, comme actuellement, on se fait incendier, sur la moitié des newsgroups américains, pour un banal message en français ?
Néanmoins, le principe me semble louable.
Toutefois, je serais curieux de voir ce que ça peut donner dans une langue en boustrophédon... mdr
-- @-salutations
Michel Claveau
Michel Claveau
Re-re !
Et aussi, si tu fais une translation en rongo-rongo, vu que c'est une langue en boustrophédon inverse (c'est peut-être la seule connue dans ce cas), faudra-t'il tourner l'écran à chaque ligne, ou as-tu prévu un utilitaire qui tournerait le bureau de 180°
Mais, MS a déjà prévu la chose : dans les tablet-PC, il y a un bouton qui tourne le bureau (de 90°, il faut donc appuyer deux fois).
:oÞ
-- @-salutations
Michel Claveau
Re-re !
Et aussi, si tu fais une translation en rongo-rongo, vu que c'est une
langue en boustrophédon inverse (c'est peut-être la seule connue dans
ce cas), faudra-t'il tourner l'écran à chaque ligne, ou as-tu prévu un
utilitaire qui tournerait le bureau de 180°
Mais, MS a déjà prévu la chose : dans les tablet-PC, il y a un bouton
qui tourne le bureau (de 90°, il faut donc appuyer deux fois).
Et aussi, si tu fais une translation en rongo-rongo, vu que c'est une langue en boustrophédon inverse (c'est peut-être la seule connue dans ce cas), faudra-t'il tourner l'écran à chaque ligne, ou as-tu prévu un utilitaire qui tournerait le bureau de 180°
Mais, MS a déjà prévu la chose : dans les tablet-PC, il y a un bouton qui tourne le bureau (de 90°, il faut donc appuyer deux fois).
:oÞ
-- @-salutations
Michel Claveau
Michel Claveau
Suite de la réponse :
x) le sulfite est une cause importante de migraine. Ma femme est très sensible aux migraines. Alors, dans le but de maintenir un bon compromis paix_du_ménage/informatique, je n'utilise que des boissons dans sulfites.
-- @-salutations
Michel Claveau
Suite de la réponse :
x) le sulfite est une cause importante de migraine. Ma femme est très
sensible aux migraines. Alors, dans le but de maintenir un bon
compromis paix_du_ménage/informatique, je n'utilise que des boissons
dans sulfites.
x) le sulfite est une cause importante de migraine. Ma femme est très sensible aux migraines. Alors, dans le but de maintenir un bon compromis paix_du_ménage/informatique, je n'utilise que des boissons dans sulfites.
