Home » Eclipse Projects » Babel » Fw: uomo in structural engineering project(forwarding discussion on missing message bundles with Babel)
| Fw: uomo in structural engineering project [message #674911]
||Sun, 29 May 2011 12:46
| Werner Keil
Registered: July 2009
Could you please help the import the UOMo message bundles into Babel?
The download site is now http://download.eclipse.org/uomo/rc2/ or (should the RC be a problem also on the preview to 0.6 http://download.eclipse.org/uomo
Luca and other Eclipse community members would be more than happy to contribute to translations or symbols still missing for certain countries and locales.
----- Original Message -----
From: "Luca Salvatori"
Sent: Friday, May 27, 2011 3:57 AM
Subject: Re: uomo in structural engineering project
> Dear Werner,
> I try and keep the discussion alive (see previous post in this tread,
> also quoted below):
> - I have noticed that some non-SI units (both in NonSI and in
> USCustomary) lack of symbol in messages.properties (e.g., inch, pound,
> pound-force, metric-ton), some other unit symbols in the same file have
> been commented. I do not see the reason (I had to add the first group
> and uncomment the second group for my test to work.
> - How does UOMo relate to JScience? You mentioned J.M. Dautelle, who
> seems now active in JScience. Are the two projects still connected
> somehow (besides using the same API)?
> Best wishes,
> Dear Werner,
> thanks for you reply.
> On 16/05/2011 00:01, Werner Keil wrote:
>> Dear Luca,
>> Thanks a lot for raising the question and exploration use
>> cases for UOMo in your structural engineering project.
>> The org.eclipse.uomo.units.NonSI class was taken from the
>> earlier (JSR) implementation, Jean-Marie, myself and others
>> had worked on.
>> It was pointed out by people at Google and others providing
>> input, that this SystemOfUnits may not have the most lucky
>> name, and seem a bit like "dump" for all kinds of units
>> that don't fit into other categories.
> I provide some more details on what I am doing, hoping that the
> description of an usage-attempt be useful.
> While exploring uomo, I needed some units already defined in NonSI (e.g.
> kilogram-force). Then I tried adding new units useful for my project.
> Indeed, I started treating NonSI exactly as you wrote: I put all new
> units in it (and upgraded the class and its constants to public, for the
> sake of my tests).
> Units I had to add for my structural engineering project are those still
> used by some practitioner engineers, for example, the metric-tonn-force,
> or the metric-technical-unit-of-mass (the mass which accelerated by 1
> m/s results in 1 kgf). I think that these units might be common also in
> other European countries besides Italy and deserve to be added somewhere
> instead than being redefined by users (such as me).
> Whether these units belong to a clearly nameable set, I am not sure. If
> it were for Italy, I would put them in an EngineeringCustomary or
> something similar. On the other hand, they may be happy to stay in
> NonSI, with their friends kilogram-force, etc.
> I agree that NonSI is quite vague and wide. Maybe some units should be
> moved to an UK specific set, and other to a "SIAffine" set, in which I
> would put units which are non-SI but whose definition is dependent on SI
> (e.g. kilogram-force, metric ton, angstrom, and those that I defined above).
> BTW, I also added some units, which, I assumed, are common in US
> engineering practice, such as kilopound (kip) and kilopound-force
> (kipf). The assumption is due to the fact that they are present in every
> US engineering program I checked. These units might be at home in
> USCustomary, but I am not in the (geographic) position to assert that.
>> Thus USCustomary was
>> created which you may notice, contains certain units for
>> the US context, which NonSI has similar UK counterparts
>> for. I'm open to constructive suggestions for a new Out of The
>> Box system similar to SI or USCustomary. Considering it is
>> final at the moment like all other unit systems, I agree,
>> its members are pretty much for internal usage only.
>> An alternative to creating further (final) default unit
>> systems would be to move the elements into
>> org.eclipse.uomo.units.AbstractSystemOfUnits making them
>> abstract and thus only available for implementing unit
> This sound interesting too. However, my first temptation when seeing a
> class named AbstractSystemOfUnits would be to derive from it (as it is
> currently done in uomo). This would end-up in having all units available
> in concrete sub-classes and this might create some confusion.
>> This would also allow usage by custom-specific unit systems,
>> i.E. if you find such need in your project or other use
>> Kind Regards,
> Kind regards,
[Updated on: Mon, 30 May 2011 13:10] by Moderator
Report message to a moderator
Current Time: Tue Oct 27 16:44:41 GMT 2020
Powered by FUDForum
. Page generated in 0.02404 seconds