[Web-erp-developers] Avoiding Choppy Translations

[Daintrees <p.d...@pa...>]

I got this message 5 times.
Is this a list issue or are you trying to make a point Jesse!!

Although I haven't come accross this much - the point is well made. We
should get Luca/Rom to take a look at this when they back into it.

Phil
----- Original Message ----- 
From: "Jesse Peterson" <je...@st...>
To: <web...@li...>
Sent: Monday, September 06, 2004 3:26 PM
Subject: Re: [Web-erp-developers] file imports for serial items


> I'd have to say it happens more than rarely. Again, my big worry is
> choppy, nonsensical  translations putting off potential users. I also
> believe that using a wrapper class, including the one I mentioned, would
> allow us to *only* use it when necessary and the _('xxx') to be used
> every other time.
> Maybe we need to get some people doing or that can do translations to
> take a look and see what effect it may have. It's just something that
> would be nice to get right the first time since there are well over 150
> scripts that have to follow which ever way we determine as best.
>
> jesse
>
>
> Daintrees wrote:
>
> >Yes this is a good thought.
> >
> >The saving grace is that variables are very rarely used inside strings.
> >Perhaps I am lazy, but I really don't see the need to go to great lengths
> >for the 2 or 3 instances of where this happens.
> >
> >The fall back where gettext is not installed on the local server is to
> >create a function that just returns the english string. Translated
> >environments thus need gettext installed. I understand that gettext is
> >pretty widely available on most web-hosts. It is widely used and tested
in
> >many environments. I am keen to stick with tried and true.
> >
> >Phil
> >
> >----- Original Message ----- 
> >From: "Jesse Peterson" <je...@st...>
> >To: <web...@li...>
> >Sent: Monday, September 06, 2004 9:18 AM
> >Subject: Re: [Web-erp-developers] file imports for serial items
> >
> >
> >
> >
> >>>Pros
> >>>1) We would need to evaluate how much further it gets the translation
> >>>compared to not using.
> >>>
> >>>
> >>>
> >>>
> >>I see it as allowing more accurate string/message translations however
> >>it will require a little more code for the developers and a little extra
> >>instruction to a translator (how to move around variables).
> >>
> >>
> >>
> >>>Cons
> >>>1) The possible slowdowns of using the class instead of built in php
> >>>processor gettext code
> >>>
> >>>
> >>>
> >>>
> >>This class allows use of php's built-in gettext libraries if they are
> >>available. This is important as I am pretty sure we could inter-mix it's
> >>use with the standard gettext function, therefor only having to use it
> >>when we needed a string with vars in it.
> >>
> >>
> >>
> >>>2) What's with the setVar?  Does that mean we need to add setVars for
> >>>
> >>>
> >every
> >
> >
> >>>var used in a string? That will be some more work.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>Yes, and yes it will be a little more work.
> >>
> >>
> >>
> >>>3) Do the tolls for making the po's such as xgettext all work smoothly
> >>>
> >>>
> >with
> >
> >
> >>>this enhancement?
> >>>
> >>>
> >>>
> >>>
> >>huh? It appears to use the same POs gen'd by xgettext if that's what you
> >>are asking about.
> >>
> >>
> >>
> >>>4) If setVar is not done on a variable then I'm thinking what will
happen
> >>>
> >>>
> >is
> >
> >
> >>>the variable name with $ will appear instead of the variable's value.
> >>>
> >>>
> >This
> >
> >
> >>>could get easily missed by various people at various times.
> >>>
> >>>5) How stable and used is this class?
> >>>
> >>>
> >>>
> >>>
> >>They use it and claim it is stable enough for their use. We will have to
> >>test it/read docs to determine it's how it functions when mis-used.
> >>
> >>The main point here, though, is that I haven't seen a more simple way to
> >>get things fully translated (as opposed to in pieces) than a wrapper
> >>like this or through complicated (s)printfs. If others think the pieced
> >>together translations will suffice, then so be it. I just would hate to
> >>have gone through this trouble and find later that people really can't
> >>stand the translations that have been done and to realize that with a
> >>little extra work at the beginning they could have been better.
> >>
> >>jesse
> >>
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by BEA Weblogic Workshop
> >>FREE Java Enterprise J2EE developer tools!
> >>Get your free copy of BEA WebLogic Workshop 8.1 today.
> >>http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> >>_______________________________________________
> >>Web-erp-developers mailing list
> >>Web...@li...
> >>https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >>
> >>
> >>
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by BEA Weblogic Workshop
> >FREE Java Enterprise J2EE developer tools!
> >Get your free copy of BEA WebLogic Workshop 8.1 today.
> >http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> >_______________________________________________
> >Web-erp-developers mailing list
> >Web...@li...
> >https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>