From: skaill <sk...@ro...> - 2004-09-07 23:00:58
|
I think it would be nice to include a software based gettext for those who don't have it installed with php. There are several reasons they may not have it installed and may not be able to do so. I believe there are some software based gettext replicas around and possibly the one Jesse is suggesting is the best. Plus it does give the opportunity in the future to do the embedded variables if we so desire down the road, even if not now. I think the important reasons for staying on the current path are: 1) We've found the standard tools and method. We know it is widely used and works. We know others have experience with it. 2) We have checked it all out to know what we're doing 3) It is not too complicated for everyone. Everyone seems to readily understand what to do which means more help too. 4) We are already down that path So maybe it's better to continue that path. There's no reason in the future why we can't do round two where we change the strings back into one piece. Granted Jesse is right that it is more work. I think several systems on the market do not go to the extent of translating with embedded variables so having the language expressed poorly in some messages is not a necessity but an advantage that could become a necessity in the future. Either way it would be nice to have eventually. Steve ----- Original Message ----- From: "Daintrees" <p.d...@pa...> To: <web...@li...> Sent: Sunday, September 05, 2004 9:11 PM Subject: Re: [Web-erp-developers] file imports for serial items > 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 |