Translations:Units/76/fr

Actions suivantes

 * Examen par d'autres personnes.
 * Vérifiez si le système actuel de gestion des unité, peut être étendu avec ces nouveaux concepts, (grandeur, signature, table de symboles, système d'unité, bases de données d'unités ...).
 * Voir avec d'autres personnes, si les limites de ce système sont acceptables :
 * La conversion (offseting) des valeurs n'est pas prise en charge par ce système. Le seul cas que je vois où un problème peut se poser, est lors du passage de degré Kelvin en degré Celsius. Je soutiens, que l'utilisateur peut le faire manuellement. Le fait est, que cette conversion peut être délicate : elle n'est pas compatible avec le concept de conversion global tel qu'il est présenté ici (cadre 1 et contexte 2) parce que lors du passage de degré Kelvin au degré Celsius, les données qui expriment une différence ne devraient pas être converties (voir l'article 8.5, page 24 Guide for the Use of the International System of Units (SI) pour plus d'explications). Autre chose, je ne sais pas si une telle conversion est nécessaire. Je n'en ai pas besoin
 * La valeur aurait pu être ajoutée en tant qu'unité de base 8. Cependant, je ne vois pas l'intérêt de la convertir : nous ne serions pas en mesure de stocker des grandeurs dans le base de données d'unité : ce sont des fluctuations journalières ! En outre, cette unité est inutile dans la modélisation par éléments finis. C'est pourquoi je propose de s'en tenir à l'idée de gérer des unités physiques . Attention, ce n'est pas parce que cette unité ne figure pas dans le système d'unités objet, qu'elle n'est pas convertible. Elle peut être définie dans la bibliothèque d'unités, avec des symboles, des grandeurs, et l'API, il y aura des méthodes pour travailler avec ces informations. Il est juste que, lors du passage au niveau mondial du système d'unité, les valeurs d'une unité monétaire ne sera pas mise à l'échelle, et l'utilisateur devra écrire une ligne de code en Python, il mettra lui-même ces données à l'échelle s'il le veut.
 * Est la même limitation à des données telles que, les dimensions d'angles (la combinaison de longueur comme $$\frac{m}{m}$$), ou, des angles solides (combinant longueur que $$\frac{m^2}{m^2}$$), c'est-à-dire qui n'ont pas d'unités. Il est possible de les manipuler, mais lors de la commutation du système d'unités, ils ne seront pas mis à l'échelle, tout simplement parce qu'il n'est pas nécessaire : leurs valeurs ne sont pas affectées par un changement d'unités de base.
 * Si c'est ok, mettre en œuvre l'unité ou la description de l'unité dans les fichiers de données de FreeCAD (ceux contenant les données sur les unités, comme les fichiers pour stocker les formes géométriques et les propriétés des matériaux).
 * Écrire dans la bibliothèque .XML des unités de FreeCAD.
 * Mettre en œuvre la notion d'unité centrale, qui doit être activée lors de l'exécution d'une instance de FreeCAD, avant d'effectuer l'échelle de l'unité, ou lors de l'importation de données, à partir d'un fichier géométrique ou d'un fichier de propriété de matière.
 * Mettre en œuvre l'échelle d'unités, lors de l'importation d'un fichier (géométrique ou de propriétés des matériaux) (correspondant au contexte 1)
 * Mettre en œuvre "sur demande" la mise à l'échelle de l'unité, lorsque l'utilisateur choisit de passer d'un système d'unité initial à un système cible (correspondant au contexte 2)