[Web-erp-developers] Standardised messages

[Phil D. <we...@pa...>]

There are always a multitude of other methods for "skining a cat" ultimatel=
y=20
my thinking is that we can have relatively standardised messages using=20
Jesse's prnMsg function with options for error, warn, success, info.=20

=46or your proposal Dick, in my view the cost benefit is too heavily weight=
ed in=20
the cost side in terms of re-development effort for insufficient benefit. I=
=20
would rather put my effort into manufacturing functionality and have=20
something great to show for it. If we used Jesse's prnMsg function througho=
ut=20
I would be most comfortable with the quality and consistency of the code -=
=20
unfortunately there are places where prnMsg is still not used.

Also, as previously noted several times I am a firm believer - perhaps=20
contrary to theory -  in having the message text interspersed with the code=
=20
to aid in code readability.

Always appreciate your experience and input though Dick.


Phil

On Saturday 20 November 2004 12:50, Zion-IT Shop www.Zion-IT.com wrote:
> yes, we are losing some of the understanding, but a short comment would
> prevent this like in the example. We get some extra quality in return for
> it. (standardised error handling, .....)
>
> You're thoughts (using constants and/or use gettext for multilanguage+0)
> might be very interesting for implementing this.
>
> Display_message procedure will be so often used that it enrich the coding
> to be easier to understand and faster to read, since it will be used
> everywhere where appropriate.
>
> With best regards,
>
> Dick Stins
>
> ----- Original Message -----
>   From: Steve Kaill
>   To: web...@li...
>   Sent: Friday, November 19, 2004 12:24 PM
>   Subject: Re: [Web-erp-developers] po tidy up
>
>
>   Ha!  If 'WE001' was instead WE001 it could be a constant/variable.  In
> that case the constant names would be in the display_messages instead of
> the actual strings and the constant strings could be all together.  Either
> way though, you start losing much of the context in terms of understanding
> and coding.  You end up having to jump around quite a bit to figure out
> whether the string(s) or parts of string(s) in multilanguage make sense
> currently.
>
>   I'm thinking in a way gettext strives to avoid this lack of context with
> its implementation and tools.
>
>   Steve
>     ----- Original Message -----
>     From: Steve Kitchen
>     To: web...@li...
>     Sent: Friday, November 19, 2004 5:18 AM
>     Subject: Re: [Web-erp-developers] po tidy up
>
>
>     Interesting points.
>
>     I have seen various implementations along these lines -
> phpgroupware/eGroupware use table based translations and have a lang
> function that does the lookup. There is also a string parser to insert da=
ta
> variables at the appropriate points in the string. This does have the
> advantage of dealing very nicely with variations in grammatical construct=
s.
>
>     The trade-off is in database access - it is guaranteed that every page
> load will have to access the db tables for its textual content.
>
>     With a system like web-ERP the db engine will be hyperactive anyway a=
nd
> disk access is the most probable bottleneck. If we store screen text in t=
he
> db as well, this will adversely affect the performance.
>
>     Of course, if fiber-channel RAID arrays were cheap, this would be the
> way to go ... :-)
>
>
>     Kitch
>
>
>     On Thu, 2004-11-18 at 23:02 +0100, Stins, Dick www.Zion-IT.com wrote:
>
>       I know it is late, but better late then never. You're example
> refreshed my memory.
>
>       In several development standards and projects, I was used to have an
> error/warning/information message coding system.
>
>       Every message should have it's own unique code/number followed with
> the text. I could happen that at different places in the code appears the
> same message like: "Wrong Code Entered".
>
>       In the system it would be coded with a function like:
>       display_message(
>         'E' ,                   //E=3Dmessage type Error
>         'A',                    //A=3Dabort script or I=3Dinformational or
> W=3Dwarning 'WE001' );        // Wrong code Entered
>
>       At another error situation:
>       display_message(
>         'E' ,                   //E=3Dmessage type Error,  I=3DInformatio=
nal,
> W=3Dwarning, ... 'A',                    //A=3Dabort script or C=3DContin=
ue or
> ... 'WE002' );        // Wrong code Entered WE=3DWeb Erp 002=3Dthe message
> number
>
>       The function will fetch the message based at the unique code  (like
> 'WE002' ) and does what it should do.
>
>       Both messages are the same, but the only difference is the exact
> place in a script where it is raised from.
>
>       When you find the exact message for more then one unique code, then
> there are a few reasons why this happens: - the message is not detailed
> enough
>       - it is coded inefficient, because the same code is repeated at
> several places, while a function/procedure is able to prevent this and
> ...... so it helps to increase the quality of the program. - it increases
> performance (but I have never seen a good example of this)
>
>       Where do you store the messages? Normally in a table, so it would be
> easy to update the messages without changing the source. An extra column
> could be entered to implement multilanguage for messages like these. May =
be
> are their other good implementation methods.
>
>       When you display also the unique code, then you will always be able
> very easily to find the exact line in a script where the error is raised
> from. That's very handy for debugging and answering questions of end-user=
s.
>
>       Sometimes, you need to be able to show parameters in a message like:
>       "You entered the wrong code: #1 in #2"
>
>       For this we need a function/procedure which allows 2 parameters.
>       display_message(
>         'E' ,                   //E=3Dmessage type Error,  I=3DInformatio=
nal,
> W=3Dwarning, ... 'A',                    //A=3Dabort script or C=3DContin=
ue or
> ... 'WE003',        // You entered  the wrong code: #1 in #2 WE=3DWeb Erp
> 002=3Dthe message number $code,
>         'index.php' );
>
>       Resume advantages:
>       - A standardised message system is good for the coding quality
>       - It is much easier to find the exact script + line where the messa=
ge
> is comming from - We would be able to update the message without the chan=
ce
> you make some typo in the script, because there is no need for updating a
> script when we need to update a message. -  improves quality, since it
> shows generic messages are not detailed enough - lot's of messages which
> are equal, tells us that there might be some code lines be coded twice or
> more or the message is not detailed enough. - .....
>
>       My suggestions is to do the following steps:
>       - do we like this? All or only parts of it or nothing?
>       - how do we want to implement this? Create a message class? And a
> table? Or use the translation package? Or ... - there  is no need to
> rewrite all scripts. I would be good enough when we use a message system
> like this for all coding which is new or rewritten for new functions.
>
>       With best regards,
>
>       Dick Stins
>       ---- Original Message -----
>
>         From: Daintrees
>         To: web...@li...
>         Sent: Thursday, November 18, 2004 8:48 PM
>         Subject: Re: [Web-erp-developers] po tidy up
>
>
>         I tried to remove punctuation - only at the end of sentences and
> broke up strings around html. Notice you did SelectOrderItems.php too - a
> misson in itself - both you and Steve did this one!
>
>         This tidy up is a misson Kitch - good job you seem to have broad
> shoulders - and chose to accept it :-)
>
>         Phil
>
>           ----- Original Message -----
>           From: Steve Kitchen
>           To: web...@li...
>           Sent: Friday, November 19, 2004 8:17 AM
>           Subject: Re: [Web-erp-developers] po tidy up
>
>
>           For me, the second option is better. Consider something like
>
>           '<BR>ERROR ! The code could not be found. Please re-enter the GL
> reference'
>
>           and
>
>           '<BR>ERROR ! The code could not be found. Please re-enter the
> customer code'
>
>
>           'ERROR' and 'The code could not be found' are common phrases th=
at
> are scattered throughout the application. When split up as suggested, only
> one instance of the text 'ERROR' and the text 'The code could not be foun=
d'
> are needed in the .po file.
>
>           Also, the current .po file is approaching 400K in size, so any
> consolidation to reduce this should be considered A Good Thing (tm) :-)
>
>
>           Kitch
>
>
>
>           On Thu, 2004-11-18 at 14:03 -0500, Steve Kaill wrote:
>
>             =EF=BB=BF
>             Although I stuck to the majority of these recommendations I
> would have one question.  What about punctuation within a string.  e.g.
>
>             '<BR> The code could not be found. Please verify and re-enter=
=2E'
>
>             What about that period and space in the middle?  Should it be
>
>             '<BR> ' . _('The code could not be found. Please verify and
> re-enter') . '.'
>
>             or
>
>             '<BR> ' . _('The code could not be found') . '. ' . _('Please
> verify and re-enter') . '.'
>
>             Steve
>
>               ----- Original Message -----
>               From: Steve Kitchen
>               To: web...@li...
>               Sent: Thursday, November 18, 2004 1:48 PM
>               Subject: Re: [Web-erp-developers] po tidy up
>
>
>               OK, I've had a look at all this stuff and here's the low-do=
wn
> ....
>
>
>               As Phil says, things are somewhat messy with duplicate
> definitions, bits of puctuation, bits of HTML and the like in the text
> strings.
>
>               I will go through all the existing modules and bash it into=
 a
> more consistent form (I must be mad ...).
>
>
>               Can I request that when you put _() strings in your code you
>
>                   do not put spaces at the start or end of the string
>                   do not put HTML tags in the string - break it up into
> pieces do not put punctuation in the string - again, break it up into
> pieces be consistent about case
>
>
>               I've made a web page to help with translating (default on t=
he
> left, your translation on the right) which I will send in when it looks a
> bit prettier :-)
>
>
>               Catch y'all later ...
>
>               Kitch
>
>               On Fri, 2004-11-19 at 11:00 +1300, Phil Daintree wrote:
> OK Kitch I got a lot of this in now - need to go back and do some double
> checking though - Jesse just sent SpecialOrder.php which missed the cut -
> its bed time here - can here knocking on the wall telling me to knock off=
!!
>
> Checking in CreditStatus.php;
> Checking in CustomerAllocations.php;
> Checking in CustomerBranches.php;
> Checking in DeliveryDetails.php;
> Checking in DiscountCategories.php;
> Checking in DiscountMatrix.php;
> Checking in Logout.php;
> Checking in SelectOrderItems.php;
> Checking in ShipmentCosting.php;
> Checking in Shipments.php;
> Checking in Shippers.php;
> Checking in Shipt_Select.php;
> Checking in ShiptsList.php;
> Checking in StockStatus.php;
> Checking in SuppCreditGRNs.php;
> Checking in SuppInvGLAnalysis.php;
> Checking in SuppPaymentRun.php;
> Checking in SuppShiptChgs.php;
> Checking in SuppTransGLAnalysis.php;
> Checking in SupplierAllocations.php;
> Checking in SupplierContacts.php;
> Checking in SupplierCredit.php;
> Checking in SupplierInquiry.php;
> Checking in SupplierInvoice.php;
> Checking in Suppliers.php;
>
> quite a flourish to finish on.....
>
> and of course
> Checking in locale/en/LC_MESSAGES/messages.po;
>
>
> Worried about introducing bugs with such a lot at break neck speed.
> I re-ran xgettext to update messages.po
>
>
> An Italian chap contacted me spelling out duplications in the .po as it w=
as
>
> which may be useful:
> > > I started translating web erp in italian, but realized that messages.=
po
> > > in italian is not complete
> > >
> > > even *.po in english seem not perfect either:
> > >
> > > --------------------------------------------------------------------
> > > bash-2.05b$ msgfmt *.po
> > > msgfmt: index.po: warning: Charset "CHARSET" is not a portable encodi=
ng
> > > name.
> > >                            Message conversion to user's charset might
> > > not work.
> > > msgfmt: messages.po: warning: Charset "CHARSET" is not a portable
> > > encoding name.
> > >                               Message conversion to user's charset
> > > might not work.
> > > messages.po:7: duplicate message definition
> > > index.po:8: ...this is the location of the first definition
> > > messages.po:20: duplicate message definition
> > > index.po:418: ...this is the location of the first definition
> > > messages.po:844: duplicate message definition
> > > index.po:414: ...this is the location of the first definition
> > > messages.po:1165: duplicate message definition
> > > index.po:293: ...this is the location of the first definition
> > > messages.po:1800: duplicate message definition
> > > index.po:29: ...this is the location of the first definition
> > > messages.po:3793: duplicate message definition
> > > index.po:410: ...this is the location of the first definition
> > > messages.po:3849: duplicate message definition
> > > index.po:378: ...this is the location of the first definition
> > > messages.po:4087: duplicate message definition
> > > index.po:390: ...this is the location of the first definition
> > > messages.po:4410: duplicate message definition
> > > index.po:209: ...this is the location of the first definition
> > > messages.po:5518: duplicate message definition
> > > index.po:149: ...this is the location of the first definition
> > > messages.po:6958: duplicate message definition
> > > index.po:189: ...this is the location of the first definition
> > > messages.po:7683: duplicate message definition
> > > index.po:153: ...this is the location of the first definition
> > > messages.po:9314: duplicate message definition
> > > index.po:21: ...this is the location of the first definition
> > > messages.po:9326: duplicate message definition
> > > index.po:257: ...this is the location of the first definition
> > > messages.po:9368: duplicate message definition
> > > index.po:265: ...this is the location of the first definition
> > > messages.po:9641: duplicate message definition
> > > index.po:25: ...this is the location of the first definition
> > > messages.po:9649: duplicate message definition
> > > index.po:33: ...this is the location of the first definition
> > > messages.po:9653: duplicate message definition
> > > index.po:37: ...this is the location of the first definition
> > > messages.po:9657: duplicate message definition
> > > index.po:41: ...this is the location of the first definition
> > > messages.po:9661: duplicate message definition
> > > msgfmt: too many errors, aborting
> > > ---------------------------------------------------------------
> > >
> > > if you can provide a valid/updated messages.po I will happily transla=
te
> > > it in italian
> > >
> > > bye
> > >
> > > xlyz
>
> A few minor points men - I'm trying to use Jesse's prnMsg function wherev=
er
> possible - this does mean there is one common way for displaying messages
> and we can muck about with the formats as we like - it is pretty
> rudimentary but I like the idea of some kind of standardisation of
> messages. Many echo statements can lose the <BR> and slot into a prnMsg
> instead.
>
> I am probably slightly autistic in my zeal for having the code nicely
> indented too - I tend to break after </TD> so the next line starts on a
> <TD> HTML in CAPS ideally. SQL broken up field by field line breaks before
> FROM. WHERE, AND, GROUP BY, ORDER BY
>
> All very picky stuff - dont bother if you dont want to I happy to have the
> code anyway you like - but I try to modify it to comply with that
> Contributing.txt doc before committing to CVS.
>
> WE DID IT!

=2D-=20
Phil