Better I18N support

thread: 9 messages  |  last: a year ago  |  started: friday, november 3, 2006, 9:55 am pst


#1  |  Justin Hall
Friday, November 3, 2006, 9:55 AM PST

Well, after researching for several months I decided to use Qcodo as a framework for a major financial application I am working on. However, since this will be used worldwide, top of the line I18N support is neccesary.

I noticed some weaknesses in your I18N methodology that I would like to point out here. However, at this point I'm probably going to port my own I18N components to Qcodo.

(1) No support for pluralization

None of the .po files give pluralization directives. Just to give an idea of the importance of this, here's how Polish plurals are determined:

   public function pluralize()
   {
       if ( ( $count == 1 ) )
       {
           return ( sprintf ( $string, $count, $plurals[0] ) );
       } else {
           if ( ( $count % 10 ) >= 2 && ( $count % 10 ) <= 4 &&
              ( ( $count % 100 ) < 10 || ( $count % 100 ) >= 20 ) )
           {
               return ( sprintf ( $string, $count, $this->_plurals[1] ) );
           } else {
               return ( sprintf ( $string, $count, $plurals[2] ) );
           }
       }
   }

Polish and Slovenian tend to be the more complicated of these examples, but without proper pluralization support it can often make an application appear unprofessional.

(2) No date, number or currency localization. Again, hugely important but seemingly missing entirely.

(3) Using a single global language file. This is a huge problem. The project I'm working on will likely have 2000+ lines of text. It would be extremely memory intensive to load the whole file into memory, even if it's cached. My system uses the view to determine the proper language file (although the header and footer are automagically loaded within the locale files as well), but the model or controller could be used as a starting point as well.

Just some thoughts, but I'm going to start work today on porting my system over. Initially my system used ini files to store data but I'm debating on whether or not to use the po files as well (I'll be doing some testing with Qcodo's cache system before I do anything).

Great product by the way, after looking at probably 20+ frameworks Qcodo was definately the one for us!

#2  |  Mike Ho (Sunnyvale, CA) United States of America Qcodo Administrator
Friday, November 3, 2006, 12:11 PM PST

Justin, thanks for your post... and thanks for your feedback!

Yes -- i18n in general was something that we added to qcodo knowing that it was “adequate” for some uses, and probably underpowered for more complex uses.

We would definitely appreciate any insight or contributions that you could provide or suggest for both i18n and with l10n.  (you'll even realize that we've placed a design in place to have things like _c() and _i() for currency and integer localization in <http://examples.qcodo.com/examples/other/print.php>, but just haven't had the time to implement it yet).

I think a lot of other members of the qcodo community (especially some of the regular members in the EU) have made a lot of good suggestions to improve i18n support in qcodo, as well.

But it would be really nice to have a good, concerted effort with one or two developers to actually improve upon (or if needed, overhaul) the current i18n support with something that is stable and simple/conveinent, and will work and scale well.

#3  |  NATHCORP (OC, CA) United States of America
Tuesday, March 9, 2010, 5:16 PM PST

Hi we are using QCODO. We want to leverage its framework for a fairly large application to localize including date, time, number formats.

Has anyone had done this successfully before?

#4  |  Mike Ho (Sunnyvale, CA) United States of America Qcodo Administrator
Wednesday, March 10, 2010, 9:23 PM PST

Qcodo doesn't have any localization support right now -- but I would highly recommend looking at Zend Framework for L10n support.

Qcodo plays very nicely with ZF, and in fact, there is already a QPM package which allows you to one-line install ZF into your Qcodo application.

See http://www.qcodo.com/qpm/package.php/zend_framework for more info

#5  |  NATHCORP (OC, CA) United States of America
Thursday, March 11, 2010, 3:16 PM PST

Mike, thanks for the response. I may not phrased my question correctly.

I am looking at the I18 support in QCODO and using that to Internationalize an application built using QCODO. I know internally QCODO uses that for localization support.

Zend looks great and may use it. Right now I am looking to see the pro's and cons of leveraging the QCODO I18N support for internationalization. Will it require extending whats already there within QCODO for I18N.

Appreciate any input. New to QCodo and figuring out how we can leverage it to the maximum.

#6  |  VexedPanda (Calgary, AB) Canada
Thursday, March 11, 2010, 3:26 PM PST

i18n can be better understood if you think of it as “translation”. Localization, or l10n is what is referred to when changing formatting of numbers and dates based on someone's location.

So QCodo supports i18n (translation), but not l10n (formatting).

#7  |  Ago Luberg (Tallinn) Estonia
Thursday, March 18, 2010, 6:27 AM PDT

Somewhat on topic:

I have proposed a somewhat different approach to QI18n here:
http://trac.qcu.be/projects/qcubed/ticket/359

It gives an option for developer to write his own translation functionality. The main reason for me for doing this was the fact, that almost every project I use qcodo/qcubed on, I use translation from database.

This gives you a possibility to write your own translation functionality, where you can do pluralization etc.

#8  |  Mike Ho (Sunnyvale, CA) United States of America Qcodo Administrator
Thursday, March 18, 2010, 9:01 AM PDT

Ago... it's definitely an interesting idea.

The only caveat I see is that one of the main reasons for PO files is so that the work of translation can be pretty easily “shipped out” to a quick, part-time / one-time helper to do the translation on the file itself, then you copy the file into your codebase, and you're done.  Having translation in the database means that the developer will likely need to be at least a bit involved with the translation process (unless you plan on building CMS-like tools within your application to manage the translation options in your database).

But I think the larger point you bring up is a good one -- which is to allow the flexibility for developers to come up with the own translation “engine”.  And of course the bonus is that the “default engine” would be the existing PO-parsing engine, so that for applications that want to continue using the PO-file based method, they don't have to do anything to change it.

Overall I like it.  It looks like you've worked on some code already -- would you want to submit it to Qcodo as a patch?  Best/easiest way would be to simply great your own branch in GitHub, and then commit your changes to the branch and post the info to it so that I can get it reviewed and then merged into the main Qcodo codebase.

Alternatively, if the changes are localized to just one or two files, then you can post them here.

Let me know...

#9  |  VexedPanda (Calgary, AB) Canada
Thursday, March 18, 2010, 2:52 PM PDT

He's already got an entire working and tested patch put together at http://trac.qcu.be/projects/qcubed/attachment/ticket/359/translation3.patch :)



Copyright © 2005 - 2012, Quasidea Development, LLC
This open-source framework for PHP is released under the terms of The MIT License.