Re: [Web-erp-developers] po tidy up

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

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 -----=20
  From: Steve Kitchen=20
  To: web...@li...=20
  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.
    =20
    In several development standards and projects, I was used to have an =
error/warning/information message coding system.
    =20
    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".
    =20
    In the system it would be coded with a function like:
    display_message(=20
      'E' ,                   //E=3Dmessage type Error
      'A',                    //A=3Dabort script or I=3Dinformational or =
W=3Dwarning
      'WE001' );        // Wrong code Entered
    =20
    At another error situation:
    display_message(=20
      'E' ,                   //E=3Dmessage type Error,  =
I=3DInformational, W=3Dwarning, ...
      'A',                    //A=3Dabort script or C=3DContinue or ...
      'WE002' );        // Wrong code Entered WE=3DWeb Erp 002=3Dthe =
message number
    =20
    The function will fetch the message based at the unique code  (like =
'WE002' ) and does what it should do.=20
    =20
    Both messages are the same, but the only difference is the exact =
place in a script where it is raised from.
    =20
    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)
    =20
    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.
    =20
    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.
    =20
    Sometimes, you need to be able to show parameters in a message like:
    "You entered the wrong code: #1 in #2"
    =20
    For this we need a function/procedure which allows 2 parameters.
    display_message(=20
      'E' ,                   //E=3Dmessage type Error,  =
I=3DInformational, W=3Dwarning, ...
      'A',                    //A=3Dabort script or C=3DContinue or ...
      'WE003',        // You entered  the wrong code: #1 in #2 WE=3DWeb =
Erp 002=3Dthe message number
      $code,
      'index.php' );
    =20
    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.
    - .....
    =20
    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.
    =20
    With best regards,
    =20
    Dick Stins
    ---- Original Message -----=20

      From: Daintrees=20
      To: web...@li...=20
      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!
      =20
      This tidy up is a misson Kitch - good job you seem to have broad =
shoulders - and chose to accept it :-)
      =20
      Phil

        ----- Original Message -----=20
        From: Steve Kitchen=20
        To: web...@li...=20
        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:

          =EF=BB=BF=20
          Although I stuck to the majority of these recommendations I =
would have one question.  What about punctuation within a string.  e.g.
          =20
          '<BR> The code could not be found. Please verify and =
re-enter.'
          =20
          What about that period and space in the middle?  Should it be
          =20
          '<BR> ' . _('The code could not be found. Please verify and =
re-enter') . '.'
          =20
          or
          =20
          '<BR> ' . _('The code could not be found') . '. ' . _('Please =
verify and re-enter') . '.'
          =20
          Steve

            ----- Original Message -----=20
            From: Steve Kitchen=20
            To: web...@li...=20
            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:=20
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=20
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=20
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=20
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=20
possible - this does mean there is one common way for displaying =
messages and=20
we can muck about with the formats as we like - it is pretty rudimentary =
but=20
I like the idea of some kind of standardisation of messages. Many echo=20
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=20
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.=20
WHERE, AND, GROUP BY, ORDER BY

All very picky stuff - dont bother if you dont want to I happy to have =
the=20
code anyway you like - but I try to modify it to comply with that=20
Contributing.txt doc before committing to CVS.

WE DID IT!