On Mon, Dec 1, 2008 at 5:31 PM, Mike Orr <[EMAIL PROTECTED]> wrote: > > There's a ticket to reinstate number_to_human_size(), one of the > deprecated Rails helpers. I left it as (1) the current implementation > is not robust enough, (2) there are two alternative implementations > which are better in different ways but arguably not ideal either. > This thread discusses the issues: > > http://groups.google.com/group/pylons-discuss/browse_thread/thread/77ea051e9dbbd6e3?pli=1 > > Nobody has followed up with suggestions for a better API spec. Should > I ask again for volunteers, leave the ticket open, or just close it? I believe your suggestion on that thread is good enough, with the little parameters change I made here http://groups.google.com/group/pylons-discuss/msg/e221dc7a7bbc4d71
do you have code for that or is that what your asking for here? > My concern is this is too implementation-specific an issue to come up > with an API that would work for a wide variety of users, which is our > threshold for helper acceptance. > there is always the case where you could copy it into your project and modify it as needed, sometimes that is better than starting from zero. as for number_to_phone, that could be changed into usphone because I really don't think there is a universal phone parser, in fact it should probably be a bad idea. From my experience doing non-us you have calling_code + country_code + area_code + number + extension calling_code is country dependent, sometime it even depends on the country your calling to and from. For example from Dominican Republic you will say 001 to call to non-USA but 1 to call USA. contry_code, is fairly normalized into a 3 digit code, for example Costa Rica is 305, Dominican Republic is 809 and 829 (last one since last year) area_code, sometimes there is a lack of country_code and this is used instead, and country code is another number number, and here is where things break some countries have followed the US standard so they have 3+3+4 digits = area_code + trunk + number but others have follow the France? standard which just adds up numbers so they have 8 or 9 digits as the number (ie no area code), and others due to international calling codes have a mix. So to summarize the fun if I'm calling from Dominican Republic to Costa Rica I'll input 011-506-ZZZZ-QQQQ XXX-YYY-ZZZZ-QQQQ where X and Y is only need if the call starts at DR. but if i'm calling from CR to CR then that will just be ZZZZ-QQQQ but the other way around (CR-> DR) 1-809-ZZZ-QQQQ 1-829-ZZZ-QQQQ X-YYY-ZZZ-QQQQ but if I'm calling from DR to DR then I need to drop the X, unless it's a cellphone. bottom line this is a total mess, and I don't think it's worth trying to push them all into one helper, maybe the strftime option is a good idea, although I think having several functions will be far simpler. So we could have number_to_XXX_phone, where XXX is the standardized 3 letter country code. > -- > Mike Orr <[EMAIL PROTECTED]> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en -~----------~----~----~----~------~----~------~--~---
