Menu
▾
▴
Re: [Web-erp-developers] Standardised messages
|
From: Stins, D. www.Zion-IT.c. <DR...@Zi...> - 2004-11-20 07:49:28
|
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
|
