Here is a patch that addresses some things about the schemas support:

1.Currently the extraction picks up every  <default> elements content even
the ones outside the <locale..... I think it should distinguish the
defaults needed to be locallized by just picking the ones which are in the
<local name="C"> block. 

2.The merging part currently works only for <locale.. blocks with a full
structure having all of default,short and long. This for obvious reason
doesnt work for many of the currently deployed schemas which only have
short and long.

3. There is no strictly defined way to provide different translations for
defaults having the same value but needing different localisation depending
on the key they apply to. I propose to introduce an addition to the default
elemnt content which will uniquely identify the particular values. For
example in clocks.schemas.in to be merged with trnsalations...

<default>@/schemas/apps/clock_applet/prefs/hour_format@12</default>

upon extraction this will be included in the pot file as 
"@/schemas/apps/clock_applet/prefs/hour_format@12"
the translator needs to translate this ot "12"

upon merging the "C" default values are sttripped from the @.*?@
and the other locales get their respective translation depending on its
availability

the text between the @ can be arbitrary given that it uniquely identifies
the default

I think this will mostly work and not create a very big burden for the
translators because in reality very few default values need to be localized.


Havoc: Kenneth wanted me to confirm with you that my idea in point 1
describes the intent of the different defaults position in the schemas.


Not sure how optimal the @.*?@ solution is but I couldnt think of anything
better.