Michael Wallner [2004-04-05 07:56 UTC] Hi, looks interesting, but:
-) it's a port to PHP but it should be adapted to the PEAR coding standards, too
-) PEAR_Error handling should be implemented
-) get_handle() should be factory()
-) there's no need for doing func_get_args() pseudo-magic in most of the methods
Mike
Alan Knowles [2004-04-05 15:42 UTC] File_Maketext is probably a better name (fits in with File_Gettext)
Hans Jürgen von Lengerke [2004-04-05 15:53 UTC] > Alan Knowles (http://pear.php.net/user/alan_k) has commented on the proposal for Internationalisation::Maketext.
>
> Comment:
>
> File_Maketext is probably a better name (fits in with File_Gettext)
I would strongly disagree with you Alan. File_Gettext is about a File format. Internationalisation_Maketext is something completely different and does not deal with files at all.
Michael Wallner [2004-04-05 17:04 UTC] I don't agree either...
I18N or I18Nv2 as prefix would probably do better.
Alan Knowles [2004-04-05 17:37 UTC] I didnt realize we actually had an internationazion category -
The preference would be to give the package a prefix (so it didnt class with any end users classes)
Internationalisation isnt a good prefix (as it's too difficult to type, and far to long...)
Locale_MakeText isnt to bad.
Languages_MakeText...
anyone else got better ideas...
I18N maybe...
Hans Jürgen von Lengerke [2004-04-05 18:55 UTC] I like Locale_Maketext, as this would be the same name as the original Perl module. Alan, I'd just not want to use the studly caps version MakeText, if that is OK with you.
Internationalisation_ is really too long and personally, I think I18N is ugly, and besides, it may cause confusion with the existing I18N(2) module.
I'm all for Locale_Maketext and it's extended Locale_Maketext_Gettext, also because this would fix a mistake I made which is having a method 'maketext()' which actually isn't a constructor. Dumb, but I'm new to PHP, and just didn't spot it until today.
So, is everybody OK with Locale_* Namespace?
If we call it that, should the Module be installed as
require('Locale/Maketext.php')
or
require('Locale_Maketext.php')
I prosume the former, but I'd rather ask you guys.
Michael Wallner [2004-04-05 19:16 UTC] Hm, I'm currently not in favour of Locale_* because it doesn't operate on locales and hardly uses locales at all (despite the one and only call to setlocale() in Maketext_Gettext, which could benefit from I18Nv2::setLocale(), so that it would work on Windows too), but I also think that decisions on the name could be taken later as well.
Most importat ATM is to make the code look more like PHP than Perl and implenting PEAR_Error[Stack] where reasonable, beside following PEAR CS.
Hans Jürgen von Lengerke [2004-04-05 19:19 UTC] I'm working on that, Michael :-)
Jan Lehnardt [2004-04-06 22:08 UTC] The code could use some pearifying but I don't think that is much of a problem. I am 100% in favour of adding this to pear. It is a valuable addition as well as a very interesting project. Hans Juergen, don't get discouraged by a somewhat unqualyfied comment.
Hans Jürgen von Lengerke [2004-04-07 06:04 UTC] > Jan Lehnardt (http://pear.php.net/user/jan) has commented
> on the proposal for Internationalisation::Maketext.
>
> Comment:
>
> The code could use some pearifying but I don't think that
> is much of a problem. I am 100% in favour of adding this
> to pear. It is a valuable addition as well as a very
> interesting project.
Hello Jan,
thanks for your support. I am currently working on cleaning up the module. This involves using phpDocumentor style comments, extending from PEAR, using PEAR_Error as Mike suggested and a probable name change to Locale_Maketext. I also must add more documentation.
Stig Bakken [2004-04-11 21:08 UTC] Sounds like a very useful package. Suggest renaming to I18N_Maketext or Locale_Maketext, to avoid cluttering the top-level namespace.
Michael Wallner [2004-04-13 18:14 UTC] Great, looks much better now, Hans Jürgen.
Despite a few (pedantic) CS issues (I know ;-) ), I wonder if it is really necessary to create functions on the fly for each message. What's the idea behind that?
ps: extending PEAR is not a requirement
Alan Knowles [2004-04-20 04:10 UTC] quick review:
factory() is a bit odd - if you want to use it with your own extended class - then you may as well not use factory.. - it also doesnt do the include to load the class..
the coding standards state that # is discouraged as a comment style..
just because gettext is aliased to _, I'm not sure its a very good idea to impelement it as a class method.
all methods aaaa_bbbb should be aaaaBbbbb
do not use short if statements eg. if ($a) dosomething();
you may want to look at:
switch (true)
case ($m == '' || $m == '['):
...
to tidy up the big if/elseif/elseif/elseif.....
Michael Wallner [2004-06-01 09:03 UTC] I don't know what Jürgen is waiting for, so I just try to raise the discussion again :)
Although we already outlined its deficiencies, I'd appreciate its inclusion in PEAR due to its advantages.
Are we OK with the name? I could also see it as Text_Maketext, although "text" would be redundant, it looks quite comprehensive.
Method names should also be studlyCaps - yeah nit-picking :)
Hans Jürgen von Lengerke [2004-06-10 09:42 UTC] OK, I have been rather busy with my dayjob lately and this will not change in the near future. So let's just get this into voting stage as is, and if the module makes it into PEAR I'll add it as alpha and I will be happy to take contributions regarding the CS issues that seem to be so important to some of you.
This framework is all about localization, the Locale namespace is absolutely appropriate (CPAN has it under that namespace too)
|
