You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2009/02/03 18:21:15 UTC
Some i18n issues
In UI, we begin to hit the Pareto principle http://en.wikipedia.org/wiki/Pareto_principle
This is a good and a bad news. It means we achieved most and to achieve the rest it will cost us (actually in our case, I'm much
more confident because we actually hitted Pareto wall earlier :o)
Typography
Typography depends on languages. For instance in French we put a space after colons, there are other cases of course. So punctuation
should be always part of labels.
HTML
We already discussed about not putting any HTML tags in labels. Actually we should at least not allow any < and & which will not be
correctly rendered (http://www.w3.org/TR/REC-xml/#dt-chardata)
I quickly noticed some problematic cases (found in French maybe ok in other languages) :
ProductRedExplanation (in Product association)
WebtoolsMessage2 (Webtools export)
WebtoolsMessage5 (Webtools import)
ManufacturingNote3 (Edit BOM)
There are certainly others, just a 1st approach
Thanks
Jacques
Re: Some i18n issues
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "David E Jones" <da...@hotwaxmedia.com>
To: <de...@ofbiz.apache.org>
Sent: Tuesday, February 03, 2009 8:12 PM
Subject: Re: Some i18n issues
>
> On Feb 3, 2009, at 11:04 AM, Jacques Le Roux wrote:
>
>> From: "Adrian Crum" <ad...@hlmksw.com>
>>> Jacques Le Roux wrote:
>>>> In UI, we begin to hit the Pareto principle http://en.wikipedia.org/wiki/Pareto_principle
>>>> This is a good and a bad news. It means we achieved most and to
>>>> achieve the rest it will cost us (actually in our case, I'm much
>>>> more confident because we actually hitted Pareto wall earlier :o)
>>>
>>> [citation needed]
>>
>> :D
>>
>> I just meaned that we are above 80% of UI accomplishment and that
>> future percentages will cost more and more (for less and less
>> benefits)... As simple as Jungle Rule...
>
> On one hand I'm pessimistic: I wish it were so and I really think we
> have a long way to go with the OFBiz UI, especially since pretty
> things and header improvements and such help (and there is still much
> room for improvement there), but only have a small effect on
> usability. I like to this of usability using the common legal term of
> "fitness for a purpose", and that implies that a well defined purpose
> is in place and is the basis for design so that users can easily
> perform common tasks. That requires a lot of specific design as
> opposed to generic design in OFBiz. The goal of OFBiz as I've stated a
> few times is to be a good basis and provide tools and generic
> functionality that make is easy to create this sort of specific
> functionality for a given intended use. We are started to approach
> some of this with the specialpurpose apps and with the Requirements
> and Designs space on docs.ofbiz.org, but ultimately we can't predict
> even the majority of what most organizations want when you get to a
> level of detail sufficient to create software that really matches an
> organization's needs. When you really design from scratch and
> implement to it (using common tools, processes, structures, etc) then
> things really vary a LOT between even pretty similar organizations and
> the flexibility to support that is what we're all about.
>
> On the other hand I'm optimistic: at least we're not close to the 20%
> of work that makes 80% of the difference. Or are we? Maybe what I
> described above about apps design to support specific activities that
> means we have the 20% generic stuff that makes 80% of the different by
> reuse in more specific apps, and not we are getting to the hard part
> of the 80% that makes up the last 20% of what users need, and that is
> unfortunately usually best done custom because that last part is so
> hard to predict and is so different in different types of companies,
> and even of different companies of the same type.
>
> A little pontificating is always fun... ;)
I love pontificate :D (anyone lurking this ML knows that already)
Jacques
> -David
>
Re: Some i18n issues
Posted by David E Jones <da...@hotwaxmedia.com>.
On Feb 3, 2009, at 11:04 AM, Jacques Le Roux wrote:
> From: "Adrian Crum" <ad...@hlmksw.com>
>> Jacques Le Roux wrote:
>>> In UI, we begin to hit the Pareto principle http://en.wikipedia.org/wiki/Pareto_principle
>>> This is a good and a bad news. It means we achieved most and to
>>> achieve the rest it will cost us (actually in our case, I'm much
>>> more confident because we actually hitted Pareto wall earlier :o)
>>
>> [citation needed]
>
> :D
>
> I just meaned that we are above 80% of UI accomplishment and that
> future percentages will cost more and more (for less and less
> benefits)... As simple as Jungle Rule...
On one hand I'm pessimistic: I wish it were so and I really think we
have a long way to go with the OFBiz UI, especially since pretty
things and header improvements and such help (and there is still much
room for improvement there), but only have a small effect on
usability. I like to this of usability using the common legal term of
"fitness for a purpose", and that implies that a well defined purpose
is in place and is the basis for design so that users can easily
perform common tasks. That requires a lot of specific design as
opposed to generic design in OFBiz. The goal of OFBiz as I've stated a
few times is to be a good basis and provide tools and generic
functionality that make is easy to create this sort of specific
functionality for a given intended use. We are started to approach
some of this with the specialpurpose apps and with the Requirements
and Designs space on docs.ofbiz.org, but ultimately we can't predict
even the majority of what most organizations want when you get to a
level of detail sufficient to create software that really matches an
organization's needs. When you really design from scratch and
implement to it (using common tools, processes, structures, etc) then
things really vary a LOT between even pretty similar organizations and
the flexibility to support that is what we're all about.
On the other hand I'm optimistic: at least we're not close to the 20%
of work that makes 80% of the difference. Or are we? Maybe what I
described above about apps design to support specific activities that
means we have the 20% generic stuff that makes 80% of the different by
reuse in more specific apps, and not we are getting to the hard part
of the 80% that makes up the last 20% of what users need, and that is
unfortunately usually best done custom because that last part is so
hard to predict and is so different in different types of companies,
and even of different companies of the same type.
A little pontificating is always fun... ;)
-David
Re: Some i18n issues
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Adrian Crum" <ad...@hlmksw.com>
> Jacques Le Roux wrote:
>> In UI, we begin to hit the Pareto principle http://en.wikipedia.org/wiki/Pareto_principle
>> This is a good and a bad news. It means we achieved most and to achieve the rest it will cost us (actually in our case, I'm much
>> more confident because we actually hitted Pareto wall earlier :o)
>
> [citation needed]
:D
I just meaned that we are above 80% of UI accomplishment and that future percentages will cost more and more (for less and less
benefits)... As simple as Jungle Rule...
Jacques
Re: Some i18n issues
Posted by Adrian Crum <ad...@hlmksw.com>.
Jacques Le Roux wrote:
> In UI, we begin to hit the Pareto principle
> http://en.wikipedia.org/wiki/Pareto_principle
> This is a good and a bad news. It means we achieved most and to achieve
> the rest it will cost us (actually in our case, I'm much more confident
> because we actually hitted Pareto wall earlier :o)
[citation needed]
> Typography
> Typography depends on languages. For instance in French we put a space
> after colons, there are other cases of course. So punctuation should be
> always part of labels.
>
> HTML
> We already discussed about not putting any HTML tags in labels. Actually
> we should at least not allow any < and & which will not be correctly
> rendered (http://www.w3.org/TR/REC-xml/#dt-chardata)
> I quickly noticed some problematic cases (found in French maybe ok in
> other languages) :
> ProductRedExplanation (in Product association)
> WebtoolsMessage2 (Webtools export)
> WebtoolsMessage5 (Webtools import)
> ManufacturingNote3 (Edit BOM)
> There are certainly others, just a 1st approach
This also goes back to CSS style best practices. We shouldn't name
things "ProductRedExplanation" because it implies a color. What if a
stylesheet changed the text color to yellow? Then the name would not
make sense. It is better to use names like
"ProductHighlightedExplanation" to indicate the text is somehow
different, but without specifying its attributes.
-Adrian