Arne,
The manifest for mobile full Q1 build can be found here:
http://cdimage.ubuntu.com/moblin/hardy/mccaslin_samsungq1ultrafull/20080222/mccaslin_samsungq1ultrafull_install-usb.manifest
This lists all packages in this particular build. Custom mobile
projects include others, like open-office.
It's difficult to know definitively which of these packages have
strings exposed. Obvious packages/package groups with UI strings
include:
* hildon packages (certainly including hildon-desktop, hildon-1,
hildon-fm)
* moblin packages (notably moblin-media and moblin-applets)
* midbrowser (the moblin browser that's based on mozembed)
* claws-mail
* open-office
* mousepad
* cheese
* drivel
* liferea
* pidgin
* galculator
* tasks
* dates
* contacts
* evince
* stardict
* fbreader
There are also system type packages like bluetooth/bluez, matchbox-
keyboard, language-selector, and some others I can't cite easily. But
this should be enough to get an idea of the kind of disk usage we are
talking about.
The total target disk footprint for Compal is "500MB, with an
additional target of 200MB". So disk space is at a premium for this
particular project, and may be for others.
Cheers,
Kyle
On Feb 22, 2008, at 10:13 AM, Arne Goetje wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kyle,
>
> if you can give me the list on applications, which will be installed
> by
> default on the mobile devices, I could find out how much disk space
> you
> would save with customized langpacks.
>
> Cheers
> Arne
>
> Kyle Nitzsche wrote:
>> Hi Loïc,
>>
>> Regarding your question (from another email thread) about the
>> possible
>> relationship between Hildon and XPI, please see the email below,
>> which
>> is all I have so far on this particular point.
>>
>> The question of what to do about Hildon i18n remains, and I tend to
>> favor modifying Hildon to use gettext properly (LP: 191375), since
>> it is
>> a gnome app after all, so it "should" be standards-compliant, at
>> least
>> in the longer term, whether made so by us or by upstream.
>>
>> By the way, I am tentatively coming to the following conclusions:
>>
>> 1) Making mobile specific lang packs would be relatively
>> straightforward
>> 2) Modifying the language-selector code to select those Mobile lang
>> packs (like it now selects KDE vs Gnome) when on Mobile would be
>> relatively straightforward. (Thanks for the separate info on this
>> Michael V.)
>>
>> Which, if true, seems to go a good way towards addressing:
>> * The goal of conserving limited disk space on Mobile
>> * Supporting the user's ability to switch to/download new languages
>>
>> Definitely looking for further discussions, comments, etc. on this...
>>
>> Cheers,
>> Kyle
>>
>>
>> On Feb 14, 2008, at 4:09 AM, Carlos Perelló Marín wrote:
>>
>>>
>>> El jue, 14-02-2008 a las 09:56 +0100, Martin Pitt escribió:
>>>> Hi Kyle,
>>>
>>> Hi,
>>>
>>>>
>>>> CC'ing:
>>>>
>>>> - Arne, our i18n guru
>>>> - Carlos, the LP translations expert
>>>> - Michael, gnome-language-selector author
>>>
>>> I added [EMAIL PROTECTED] to the CC so the whole translations
>>> team
>>> knows about this.
>>>
>>>>
>>>> Kyle Nitzsche [2008-02-07 17:13 -0500]:
>>>>>
>>>>> Current project
>>>>> The background is that for our current custom Mobile project, we
>>>>> need to
>>>>> support English, French, German, Spanish, Traditional Chinese and
>>>>> Simplified Chinese. We intend to use SCIM input methods. User can
>>>>> switch
>>>>> locales. And download new languages.
>>>>> This seems to involve:
>>>>> --gettext in the code
>>>>> --handing apps with non gettext code (mozilla/ooo/fbreader) (I
>>>>> need
>>>>> pointers here).
>>>>
>>>> We don't have a complete solution for this yet. The long-term
>>>> goal is
>>>> to have LP translations support these applications and import/
>>>> export
>>>> their native format, so that we can ship them in the normal
>>>> language
>>>> packs.
>>>
>>> ooo support in Launchpad is going to be done with translation-
>>> toolkit,
>>> mozilla support is being implemented right now as a native format
>>> and I
>>> don't know about fbreader format, where could I read more about
>>> its file
>>> format?
>>>
>>> [...]
>>>
>>>>
>>>>> Launchpad
>>>>> Naturally, we'd like to leverage launchpad for completing needed
>>>>> translations. I suppose if is everything is in main by the
>>>>> appropriate
>>>>> deadline, we can get any needed translations done there.
>>>>
>>>> Last time I checked the msgids in hildon ("C" locale) were some
>>>> string
>>>> codes, not the English strings. LP translations currently cannot
>>>> deal
>>>> with this, it assumes that C == some accent of English.
>>>>
>>>> IIRC LP translations should eventually grow a feature to translate
>>>> between languages, not just from C to a language (e. g. translate
>>>> German into Greek). Once we have this, it should be painless to
>>>> support the "C is just a code" use case. Carlos, is that right?
>>>
>>> Actually, Hildon's .po files do the same as Mozilla XPI files, and
>>> we
>>> have the infrastructure to support Mozilla XPI files already in
>>> Launchpad so it's a matter of extending it to Hildon's .po files.
>>> To do
>>> this, we need a way to detect automatically (or in worse case,
>>> manually)
>>> which files are using .po file formats in that way. If all
>>> Hildon's .po
>>> files has an specific header or filereference or anything that could
>>> differ from any other standard file, that would help us to auto
>>> detect
>>> it and activate the automatic mapping of IDs with English
>>> translation.
>>>
>>>>
>>>> However, we don't have it right now, and I wouldn't bet on it for
>>>> Hardy. Is there a possiblity to convert hildon to use en_US as C?
>>>
>>> If it's a must, I'm sure we could have it for Hardy. As I said, the
>>> infrastructure is already in Launchpad code, is not something we
>>> need to
>>> add (except the way to tag those Hildon files as using that
>>> 'weird' way
>>> to handle translations).
>>>
>>>>
>>>>> However, I am wondering about the hardy deadlines, which indicate
>>>>> a user interface freeze of Feb 28. Does this mean that if we do
>>>>> further work on the UI after that date we won't be able to
>>>>> translate via launchpad?
>>>>
>>>> This just means that we should stop changing strings. We can still
>>>> continue to translate them until LanguagePackTranslationDeadline on
>>>> April 17 (see [2]).
>>>
>>> And even after that, providing language pack updates ;-)
>>>
>>>>
>>>>> Miscellaneous
>>>>> How to enable user switching locale? (which package?). Are the new
>>>>> locales auto generated?
>>>>
>>>> See above.
>>>>
>>>>> Should we consider pre-loading all mobile translations at build
>>>>> time so
>>>>> the user would only have to switch locale, or should we enable
>>>>> downloading new languages?
>>>>
>>>> Both is technically possible. The mobile team should decide on
>>>> this,
>>>> depending on how much space you have on the devices, how big
>>>> installation media can/should be, whether you expect users to be
>>>> connected to the internet, and whether you will adapt
>>>> gnome-language-selector.
>>>>
>>>> Martin
>>>>
>>>> [1] https://wiki.ubuntu.com/TranslationLifecycle
>>>> [2] https://wiki.ubuntu.com/HardyReleaseSchedule
>>>
>>>
>>> Cheers.
>>>
>>>
>>> --Carlos Perelló Marín
>>> Ubuntu => http://www.ubuntu.com
>>> mailto: [EMAIL PROTECTED]
>>> Alicante - Spain
>>>
>>>
>>>>
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHvuZ8bp/QbmhdHowRAn8hAJwKvWDkv5mcn72n1EoSGlVkcj0V0ACgnaR4
> otPqcfzhykHnTMSqKE8FdZg=
> =49+X
> -----END PGP SIGNATURE-----
--
Ubuntu-mobile mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
