Re: [Web-erp-developers] Standardised messages

[Steve K. <sk...@ro...>]

Jesse's prnMsg goes a tremendous way toward standardizing all of the
messages.  In the process it cuts down significant extraneous code and can
be relied upon to produce consistent looking messages everywhere in the
system.  All the work has just been completed, and it is a lot of work, in
order to get all these benefits.

I lean toward having strings readily viewable within.  That's my take
anyway.  I believe not many would comment clearly and the name/constant
would end up cryptic as well thereby causing confusion and switching between
files and manual lookups in order to get any coding done.

Steve

----- Original Message ----- 
From: "Stins, Dick www.Zion-IT.com" <DR...@Zi...>
To: <web...@li...>
Sent: Saturday, November 20, 2004 2:53 AM
Subject: Re: [Web-erp-developers] Standardised messages


> Phil,
>
> It is not that heavily weighted to use unique messages codes in prnMSG
> instead of the current strings and do the translation in the prnMSG
> functions.
>
> prnMsg( _('The company record has not yet been set up</B><BR>From the
system
> setup tab, select company maintenance to enter the company infomation and
> system preferences','error','CRITICAL PROBLEM') );
>
> Would be then:
> prnMSG(
>   'SQLCommonFunctions001', //company record has not been setup
>   'error',
>   'CRITICAL PROBLEM'
> );
>
> Displaying the message should be in prnMSG then:
> Echo $msg . '_'  . getMSG(  $msg, $type, $prefix );
>
> + some minor change in getMSG
> return '<font color="' . $Colour . '"><b>' . $prefix . '</b> : ' . _(
$msg )
> . '</font>';
>
> We can use a new function prnMSGc with implements this for a smoothly move
> to this new system.
>
> With best regards,
>
> Dick Stins
>
> ----- Original Message -----
> From: "Phil Daintree" <we...@pa...>
> To: <web...@li...>
> Sent: Saturday, November 20, 2004 3:05 PM
> Subject: [Web-erp-developers] Standardised messages
>
>
>
> There are always a multitude of other methods for "skining a cat"
ultimately
> my thinking is that we can have relatively standardised messages using
> Jesse's prnMsg function with options for error, warn, success, info.
>
> For your proposal Dick, in my view the cost benefit is too heavily
weighted
> in
> the cost side in terms of re-development effort for insufficient benefit.
I
> would rather put my effort into manufacturing functionality and have
> something great to show for it. If we used Jesse's prnMsg function
> throughout
> I would be most comfortable with the quality and consistency of the code -
> unfortunately there are places where prnMsg is still not used.
>
> Also, as previously noted several times I am a firm believer - perhaps
> contrary to theory -  in having the message text interspersed with the
code
> 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
> data
> > variables at the appropriate points in the string. This does have the
> > advantage of dealing very nicely with variations in grammatical
> constructs.
> >
> >     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
> and
> > disk access is the most probable bottleneck. If we store screen text in
> the
> > 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=message type Error
> >         'A',                    //A=abort script or I=informational or
> > W=warning 'WE001' );        // Wrong code Entered
> >
> >       At another error situation:
> >       display_message(
> >         'E' ,                   //E=message type Error,
I=Informational,
> > W=warning, ... 'A',                    //A=abort script or C=Continue or
> > ... 'WE002' );        // Wrong code Entered WE=Web Erp 002=the 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-users.
> >
> >       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=message type Error,
I=Informational,
> > W=warning, ... 'A',                    //A=abort script or C=Continue or
> > ... 'WE003',        // You entered  the wrong code: #1 in #2 WE=Web Erp
> > 002=the 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
> message
> > is comming from - We would be able to update the message without the
> chance
> > 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
> that
> > 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
> found'
> > 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:
> >
> >             
> >             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.'
> >
> >             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-down
> > ....
> >
> >
> >               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
> the
> > 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
> was
> >
> > 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
> encoding
> > > > 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
> translate
> > > > it in italian
> > > >
> > > > bye
> > > >
> > > > xlyz
> >
> > A few minor points men - I'm trying to use Jesse's prnMsg function
> wherever
> > 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!
>
> --
> Phil
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers