On Nov 11, 2007, at 15:23 , korakurider@yahoo.co.jp wrote:
Bert Freudenberg bert@freudenbergs.de wrote:
A SAR may or may not be the best packaging. It could actually extract a .mo to the default directory, so we would just have to support an additional path for .mo files.
Current gettext emulation stuff can support search path list
for MO and even dynamic registration of additional path. so it is easy to add the default path (that is sand box of rainbow, right?) to search list. Difficult part is that the registration have to be restored also.
(I think we need to start write down "the good practice for app on OLPC Etoys" to document the rule / convention. This discussion is the first step.)
Yes ... people will have to get familiar with Sugar I fear. We can't abstract away everything.
So only way to provide translation for apps is that preload apps and rename image and package them as RPM. I would like to hear your thought.
No, apps must be packaged as .xo files. We will just have to find a way to support this. SImilar to what I did with the DiceWars xo bundle a while ago.
As I have been working without Sugar/emulation environment, I
haven' t figure out what is the hurdle to support it...
Once OLPC has some XOs to spare we should definitely get you one. Thanks for doing all this work without even being able to test directly!
When I find a bit of spare time I will look into Sugar in an emulator again. It's too bad that not even the stable build is working :(
(I understand we have similar issue with additional font...)
The font can simply be saved in the default directory, just as we do now I think.
No, I was refering about not saving font file, but registration of
additional font to image and its restoration, as you and Luke are discussing in http://dev.laptop.org/ticket/4604
Ah. That problem will be solved when we switch to Pango - we do not have to import the fonts anymore. Not for Update.1, unfortunately.
- Bert -