Situation 1:

You go to the supermarket and buy a new PC, you’ll find that the installed copy of Windows is perfectly localized in your language by default.

Situation 2:

You go to the Apple store and buy a new MAC, you’ll find that the installed copy of MAC OS is perfectly localized in your language by default.

Situation 3:

You download a copy of Ubuntu, burn it and boot it, select your language and… find that half of the system is in English and only a few things are in your language (this happens for Italian, maybe things can be worst with other languages).

What I want to say it’s quite obvious, if Linux vendors want to penetrate the newbies market, they must provide fully localized ISO images, there are no excuses. This is my point of view.

A lot of time ago, when I entered the UCK team, I wanted to build an ISO localization team, to build and deliver a full set of Ubuntu localized images. That part of the UCK project never came to life because of some problems but I still believe in its importance. Ubuntu team seemed to be quite regardless of this problem and our solution.

We (CreaLabs) continue to build and deliver the Ubuntu Italian ISO and I know there are a few other similar projects around the world but the point is that these kind of initiatives should become more officially endorsed by Ubuntu (or any other distro, problem is the same).

I talked a few time with the Ubuntu Italian Community but in all these years no page of the site links to our ISO image. Well… I’ve to say I’m a bit sad about that ’cause this seems to mean something like “we don’t care about that”.

Now, critics apart what can/should we do? If you agree with my point of view contact your distro (many of them have localized communities) and make them read this post, we just need to talk about the problem and we’ll find how to solve it. Having a fully localized Linux delivering infrastructure can only bring more users to our beloved OS.

Share/bookmark:

I want to wish you a marry Christmas with a small update on P4A 3 development status. Here you have the changelog since last update:

- P4A_Image was removed
- P4A_Icon was renamed to P4A_Image
- P4A_Button::composeStringProperties() method was removed
- P4A_Image::setIcon() now supports a path to an image instead of the icon name
- P4A_Toolbar::enable() and disable() methods params were removed
- P4A_Toolbar::addLabel() method was renamed to addBox()
- P4A_Toolbar::setOrientation() method was removed because it was not implemented
- jQuery::dimensions plugin was updated to 1.2
- DHTMLCalendar by dynarch was dropped and replaced by jQuery::UI::datepicker 3.2
- P4A_Field::getAsDate() now it’s fully working with the jQuery::UI::datepicker with an additional ajax call to reformat the date
- P4A_DB::getLikeOperator() and setLikeOperator() methods were added, like operator (LIKE/ILIKE) is autodetected and it’s useful when you’re generating a query
- P4A_Field’s autocomplete was ported to P4A_DB::getLikeOperator() thus now it should work better with different databases (eg: postgreSQL)
- P4A_Widget::raise() method was removed
- P4A_I18N::getLocaleEngine() method was added to retrieve a copy of the Zend_Locale object
- standard.php library file was cleaned removing PHP4 functions
- P4A::getP4AJavascript() method was added, it will return a bunch of javascript code needed for P4A initialization
- jQuery::UI::datepicker was localized using Zend Framework data, no need to sync with datepicked localization files

and the updated TODO:

- check p4a_button sizes when we have a toolbar with buttons with icons and without icons
- implement application level translations
- port sample_i18n to the new translation system
- spread about the new translation system so users start translate
- check db_source for aliases
- try to detect the decimal format and use it during formatting
- check p4a_table ordering
- custom formatter for date/time/etc
- change p4a_table_col image handling, we’ve to pass by index.php and not phpthumb.php
- integrate p4a_base_mask in core and port samples to it
- auto addaction on intercept and implementmethod when the action is a browser action
- implement db_source::setquery, maybe separate db_sources?
- implement db_source::setZendSelect or something like that, maybe separate db_sources?
- implement p4a_table::addCheckboxCol
- p4a_table action col should also support html (for images)
- remove P4A_Toolbar::getAsString() method with its strange behaviour?
- generate datepicker “firstDay” telling which is the first day of the week (we’ve to wait for ZF fix about that)

Now let’s rest for a couple of days :) marry Christmas to everyone!

Share/bookmark:

Following the previous post, here you have the new things I’ve coded:

- POT file for the new translation system was prepared and committed to p4a/i18n/templates/p4a.pot
- P4A_Generate_Default_Label() global function was added, it takes a string such as “this_is_field” and returns “This is a field”, useful to generate labels from field names and other things
- P4A_Button and P4A_Widget were ported to P4A_Generate_Default_Label() to generate default labels
- default labels are now generated with ucfirst function instead of ucwords
- P4A toolbars and P4A_Table were ported to the new translation system
- translations are now applied at rendering time, not at build time
- P4A_Highlight_AccessKey() global function was added
- P4A_Widget::setLabel() does not automatically create accesskey now, it would cause problems with translations
- P4A_Object::intercept() and P4A_Object::actionHandler() now turn action name to lower before processing
- P4A_Menu now uses P4A_Highlight_AccessKey()
- P4A_Widget::setValue() and getValue() methods were removed because they’ve not all widgets have a value
- P4A_Button::setValue() and getValue() methods were removed, use setLabel() and getLabel() which are logically correct
- README file was updated, dropping some old browsers support and removing PHP4
- P4A_Button are now rendered as HTML buttons
- P4A_Button::setVisible() method now has a second parameter “visible”, check the reference
- all constructors were converted to PHP5 naming (public function __construct)
- P4A_Button::setIcon() now supports a path to an image instead of the icon name
- “currency” format/normalize was removed, it was never used and should not be handled in an application contest (you won’t print € only because your application is running with an european locale)
- P4A_Href widget was removed
- P4A_DB::limitQuery(), selectLimit() getError(), getNativeError(), query() and close() methods were removed because they can’t work with Zend_DB
- P4A_DB::rollback() and select() methods were added
- P4A_DB::fetchOne(), fetchCol(), fetchRow() and fetchAll() methods were added for Zend_Db naming convention compatibility
- P4A_Fieldset now uses getLabel() instead of getTitle() to render its legend, setTitle() and getTile() are now deprecated
- P4A_DB::get*() and query*() methods are now deprecated

and my updated TODO:

- check p4a_button sizes when we have a toolbar with buttons with icons and without icons
- implement application level translations
- port sample_i18n to the new translation system
- spread about the new translation system so users start translate
- check db_source for aliases
- try to detect the decimal format and use it during formatting
- check p4a_table ordering
- custom formatter for date/time/etc
- make ui.datepicker.js work with our new date format definitions (maybe call p4a by ajax to reformat)
- change p4a_table_col image handling, we’ve to pass by index.php and not phpthumb.php
- integrate p4a_base_mask in core and port samples to it
- remove p4a_icon and port its funcionalities inside p4a_image
- auto addaction on intercept and implementmethod when the action is a browser action
- implement db_source::setquery, maybe separate db_sources
- implement p4a_table::addCheckboxCol

Share/bookmark:

Back from the weekend in Dublin it’s time to write an update on my nightly coding sessions on P4A 3.

Well, a bunch of things were already done, porting to Zend Framework seems to be easier than what I expected, I’m working hard (you know time is always low) and I still have many many things to do but things start working and this is really exciting.

Here you have a changelog of what I did in the past weeks:

- Zend Framework 1.0.3 was added
- Database connection now relies on Zend_DB PDO adapters
- check_configuration.php was ported to Zend_DB to check the database connection
- P4A_DB_Source was ported to Zend_DB (not completely done and tested, check the TODO list)
- P4A_DB_Source::setFields() syntax was changed, now you must provide only fields from the main table and not from joines ones
- P4A_DB_Source::addJoin() syntax was changed, join type param was dropped and now you have a third param to pass the columns you want to extract from the joined table (default extracts all columns)
- P4A_DB_Source now has many methods to add joins: addJoinCross(), addJoinFull(), addJoinInner(), addJoinLeft(), addJoinNatural(), addJoinRight()
- P4A_I18N does not manage charset anymore, only UTF-8 will be supported from now on
- P4A_I18N numbers format/normalization now relies on Zend_Locale
- P4A_I18N dates format/normalization now relies on Zend_Date and Zend_Locale
- P4A_I18N::getCountry() was renamed to getRegion()
- P4A_I18N::autoFormat() was renamed to format()
- P4A_I18N::autoUnFormat() was renamed to format()
- P4A_Number format/normalization class was removed
- P4A_Date format/normalization class was removed
- all P4A i18n format definition files were removed
- translation messages files were reorganized and renamed
- days and months translations were removed from translation messages files (now they’re provided by Zend_Locale)
- yes/no translations were removed from translation messages files (now they’re provided by Zend_Locale)
- boolean normalization works much better now (eg for italian language: it detects “sì” or “si” or “s” without case difference and the same engine works for every language)

and a TODO list of what I need to keep in my mind:

- “time” format/normalize
- “currency” format/normalize
- move translations to Zend_Translate (in progress)
- check db_source with multivalues
- check db_source for aliases
- make ui.datepicker.js work with our date format definitions
- rename constructors to __construct

Many of you would like to know what we’ll do with the graphic layer… actually we’ve decided to stop experiments on extjs and other javascript frameworks, they’ve been too time-consuming and we found bugs and limitations thus, at the moment, we’re keeping the old rendering layer. Being real, I think that P4A 3 will still generate the HTML markup but we’ll rewrite the CSS from scratch without relying on javascript frameworks that seem to not fit our needs.

Stay tuned! ;-)

Share/bookmark:

There would be so many things to tell… I’ve been working hard (sleep? what’s sleep?) on P4A 3, I was too excited about the new possibilities to wait, more info will come later.

Next week will be totally distructive but I hope I’ll be able to post something and code a bit.

And now… Dublin I’m coming for the weekend!!! :-D

Share/bookmark:

Changelog:

- Major bugfix on P4A_DB_Source::saveRow(), the patch from Edr (introduced in 2.2.0) was removed and a few checks were added to prevent inconsistency
- some little bugs on P4A_DB_Source were fixed

Download P4A 2.2.2

Share/bookmark:

This post will not be easy to write… I’ll try to explain you what kept us really busy in the past 2 weeks. ok a screenshot could help me :-)

In the P4A 3 roadmap post, I told you about a new widget rendering system… I didn’t post more technical info intentionally, I wanted to create a bit of suspense :) but I also wanted to do some tests before publishing news.

For P4A 3 we’d like to have a killer graphic with killer features (resizable widgets, border layouts, beautiful and powerful menu and so on) thus we looked to the biggest javascript frameworks out there: extjs and dojo. Both have great features and both have issues.

Extjs as really a killer graphic layout, and it’s released under LGPL3 (developers wrote some licensing notes that I can’t really understand… actually I think that those notes could conflict with LGPL3 itself) but it has not an open SVN and development is quite closed. Another note: only community support is for free.

Dojo is more polite with licensing and it’s released under BSD, but I don’t like the graphic layout too much and the way you’ve to code your applications writing a non-standard HTML with dojo-only attributes. It has some accessibility features.

Some considerations:

• In my tests I found bugs in both frameworks
• porting P4A to one of these tools is a “1 way road”
• relying the rendering layer to a 3rd party project means we’ve to 1000% trust this project
• these tools do not have a good print CSS support

We would have a 3rd option: continue on our road with quite standard HTML but rewrite our CSS from scratch with a CSS reset and a modular design which will give us better control.

I wrote extjs developers to know if they’re interested in a collaboration with P4A, I’m waiting for an answer but I’m looking for your considerations too, community it’s important to me, please let me know what you think and what are your experiences with those tools (or suggest others).

Share/bookmark:

The new beautiful interface for scanning media? Think gnome should add it by default and hemmmm… ubuntu? can someone please drop xscan? ok xscan works but it’s 2007, think we deserve a better interface…

just a thought

Share/bookmark:

Changelog:

– multicheckbox field and multiselect field now support saving in single table field
- P4A_Field::setMultivalueSeparator method was added
- a bug with images on p4a_table wal solved
- rich_textarea “Full” theme was added
- jQuery::form was updated to 2.01
- a bug with empty “file” fields submitted with an ajax call was solved

Download P4A 2.2.1 here

Share/bookmark: