[Chandler-dev] [Sum] May 29 - June 4

[Katie Capps Parlante]

i18n (and one or two other dev topics)
--------------------------------------
*PyLucene in the MVA project*
Philippe summarized a discussion with Andi about using PyLucene in Xun's 
summer of code project. PyLucene may not be very useful, but Lucene has 
a "scanner" and a "synonym" function that might prove useful.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005998.html

*Python eggs and i18n*
John sent out notes from the meeting on python eggs and i18n. 
Agreements: (1) Python eggs will be used as the mechanism to deploy 
language translations for Chandler and as the mechanism to distribute 
Chandler parcels. Python eggs may contain parcels, language translation 
files, and i18n resources. (2) We'll invest in build work to minimize 
overhead for development against multiple eggs. (3) There will be only 
one gettext translation domain per Python egg. Implementation options: 
(a) At Chandler launch, mo files in eggs that are not in an mo 
installation directory will be copied to that directory. In the long 
run, the end user would get a pre-built repository + mo installation 
directory, so the end user wouldn't incur the overhead unless installing 
new language eggs, and then only once. (b) Instead of copying files to a 
directory, a dictionary is setup in the repository during parcel 
installation, mapping locale to paths to mo files in the eggs. Option 
(a) would work with non-Chandler Python projects, no dependency on the 
repository. It has the disadvantage of storing two copies of each mo 
file. (b) We can use the existing parcel install mechanism, so possibly 
simpler to implement. On the con side, language translations are not 
available until the repository is opened. Possible workarounds include a 
well known path for core translation files.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005999.html

Phillip Eby noted that for option (a), it would be important to not 
remove mo files when starting up with a clean repository, to make life 
easier for devs. He also explained that both approaches would use an 
identical API for the developer; installParcel() hook is the opportunity 
to invoke the API to register or copy the resources. We could use one 
approach initially and switch later without impact to egg developers.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006016.html

Heikki and Markku will decide on an implementation plan, first cut 
expected in a week.

*Branding Chandler and i18n bootstrap*
Heikki brought up the question: how would we enable an ISP or some other 
vendor to "brand" Chandler? He noted there would need to be a way to 
replace the vendor string, app name string, icons/images and welcome 
note text. Full skinnability might be nice, but probably not required. 
Heikki asked if we could use i18n support, which brings up the issue of 
needing some of these strings before the repository is open. Error 
dialogs face the same problem -- i18n support is needed during the 
bootstrap process. He also observed that a brand is not a locale.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/006002.html

Brian opined that the i18n framework is not the right place for branding 
strings. He recommended a config or startup file, the equivalent of 
Info.plist on OS X.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/006004.html

Philippe pondered his "make splash screen localizable" task -- perhaps 
it should fetch strings from a config file, branding or not.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/006005.html

Brian pointed back to the i18n meeting (see above). If we use the 
repository to register localizations, then we need some external subset 
of localizations for bootstrap before a repository is created, probably 
found in a well known location.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/006006.html

*Unit and Functional Tests updated for Unicode*
Brian explained that tests have been updated to use strings containing 
non-ascii characters. A unicode wrapper method "uw" was added to the 
i18n.tests package. This method wraps an ascii string with unicode 
characters for testing. Updating the tests revealed some common errors, 
including sending unicode objects to the Python logger (which doesn't 
accept them -- devs should encode unicode objects as utf8). Ditto for 
use of the file system API. Another no-no is using string casts 
"str(someUnicodeData)". Coming soon: locale awareness of date, time, 
number and display strings. More details and examples in the post.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/006008.html

Heikki discovered that sys.getfilesystemencoding didn't work properly on 
  Windows. Brian fixed this by using utf-8 instead, as this is supported 
on all 3 platforms.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/006010.html

Heikki noted that "uw" being non-deterministic is a problem for testing, 
as results aren't quickly repeatable. He also requested some mechanism 
to always test with an extended ascii value. Heikki and Brian agreed to 
Bryan's suggestion that we select the Unicode characters to add based on 
the input string, Brian will implement. Heikki offered a refined 
proposal: select the first unicode character based on the input, 
hardcode the second character to be a value that doesn't fit in extended 
ascii.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006015.html

*i18n build script*
Bear proposed we add a gen_i18n.sh script to chandler/tools (gathers and 
generates i18n related data). The script could be parameterized to 
handle different parts of the process. It would allow him to add a 
simple target to the make file and be a script anyone could run. Bear 
later noticed that it was discussed in IRC, and included a transcript. 
The conclusion was that a build target is not needed and Markku will 
create any required helper scripts.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006018.html

*discarding bad data*
Heikki inquired about the possibility of discarding bad data as a way to 
help degrade gracefully. Andi answered that there is no easily 
identified generic bad data at the repository level. If very low level 
data is bad (bdb data file corruption), Berkeley DB tools might help but 
this is non-trivial. If a repository bug allows bad data to be committed 
(e.g. dangling ref), code could be added to recover, Andi has been 
thinking about this. If a bug in the app causes data that is good from 
the repository's view to be bad, the app needs to detect it and recover. 
The repository could provide an API to let the user tell the repository 
to discard the most recent version(s) committed until the app is happy 
again. Perhaps this could be added to Bryan's recovery dialog, a user 
controlled rollback utility. This is on Andi's todo list.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006019.html

Meetings and announcements
--------------------------
Philippe posted notes from various sprint week activities, including an 
i18n meeting, a cpia meeting, a build policies meeting and Alec's review 
of collections.
http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/006003.html

Apps meeting notes (highlight: Brian K joining apps team)
http://lists.osafoundation.org/pipermail/chandler-dev/2006-June/006013.html