What we trying to achieve
David Smid
Let's forget the whole toolization thread and let's start over again.
I think the whole thing is one great misunderstanding.
Please read carefully what others are posting, be tolerant, if anything
is unclear, don't be afraid to ask. If one sentence could have two
different meanings, choose the nicer one.
Take your time before posting, sum up your thoughts, make sure your
sentences are clear and cannot be misunderstood. You don't have to react
immediately, quality is better than quantity.
Remember, we are of different nationalities, what can be taken as
offense in one culture could be OK in others.
To the topic of this message:
I think we want to achieve these two major things:
1) To have some structure containing the translations, to be able to
organize them, to enable our members easily edit and submit the
translations.
This structure can be locale oriented or package/gettext_domain oriented.
By gettext_domain I mean the base name of translation .mo file as it
appears after it is installed in /usr/share/locale tree.
There are three ways of submitting changes, ordered by convenience:
Web interface, svn commit, submit by mail
Web interface means Launchpad or Pootle.
We could have single SVN repository or we could have also an additional
SVN repository (contribution repo) for safety reasons.
My opinion: if we would have a web interface, we would not need many SVN
accounts. But if we would have only SVN access, we should make account
for anyone we trust.
2) To have some l10n package release system and some repository for
testing such packages.
Maybe you don't agree with me on this. But just for the case our efforts
would be ignored we need some way of distribution we have total control
of. RPMs generated by this system can be also used to easily test the
translation updates.
This structure must be package/gettext_domain oriented and should live
in an SVN repository.
We should also run our own APT/RPM repository to be able to test
cohabitation with core packages, package updates, package removing, etc.
Please gentlemen, put aside your personal feelings and try to be
constructive.
David
Alessio Adamo
- svn with shared administration for submitting po files
- in the case this is seen as a hazard, a buffer svn could be used (it can even be an exercise to be able then to use the primary one), but definitely not an email system
- we need rpms to test. Hopefully the devs will give our work the right value and so we could just repackage the original rpms, otherwise we'll have to package rpms for that locale updating system we already discussed at the start of our group
- to make testing easier, it would be extremely useful a testing locale repository
- our mailing list is useful and already working great. I would not change it.
- the google wiki as well, I think, can satisfy our needs
- I don't think we need our blog. I would report our major achievements on the front page of mypclinuxos.com. Maintaining this connection in my opinion is fundamental.
David Šmíd
- I don't think we need our blog. I would report our major achievements on the front page of mypclinuxos.com. Maintaining this connection in my opinion is fundamental.
I can't say anything about pootle or launchpad because I had and have no time to test them (at the moment). But if using them would mean having po files scattered in many web pages, I prefer svn.
Please take a look at Pootle - demo site: http://pootle.locamotion.org/, features: http://translate.sourceforge.net/wiki/pootle/features
I think it isn't as complex and hard to administer as Launchpad, it's not so heavy-weight solution but still could perfectly fit to our needs. It can happily coexist with SVN and would be very convinient to use for less experienced translators. The whole hassle concerning commit methods could be made obsolete by Pootle. Anyway, I'll try to install it somewhere and then I'll report my findings.
David
Alessio Adamo
We don't need a "blog", we need a web page with detailed status. Such details wouldn't interest anybody on mypclinuxos.com. Yes, we should report our major achievements on mypclinuxos.com as well.
Please take a look at Pootle - demo site: http://pootle.locamotion.org/, features: http://translate.sourceforge.net/wiki/pootle/features
I think it isn't as complex and hard to administer as Launchpad, it's not so heavy-weight solution but still could perfectly fit to our needs. It can happily coexist with SVN and would be very convinient to use for less experienced translators. The whole hassle concerning commit methods could be made obsolete by Pootle. Anyway, I'll try to install it somewhere and then I'll report my findings.
I had time to have a look at pootle, and i think it might be perfect for our needs. You can open a single project for many po files and those graphs are also useful.
I think we should give it a try. Do we start a pclos project then?
Ramboz Pierre-Henri
Or so i guess !
not pclinuxos !
Confusion and iprecisions can lead to disaster in the project we are dealing with ... I understood what you ment ... not sure everyone did.
DidouPh
Zoltan Hoppar
I think Pootle will be great, if we have inside the frozened reference strings of epmty pclos pots. All of it, no exeptions - tools, extra apps, base apps. If we can reach this clear point of start, where all of the team could and should (re)arrange the lines. With this, it could be usefull if new team is arriving, and it would be also usable to get every existing translation to it's place.
If we could to turn texts and attention, care into pootle's web interface, later we get less and less problems from it. I could be pulled to SVN, get packed by Santa - to have an happy xmas.
(By the way from the Santa proj. we need repackers lately who must be part of translation process, and this talk - who extracts for us spec files and converts them to POT's.)
Am I right?
Zoltan
David Smid
> I had time to have a look at pootle, and i think it might be perfect for
> our needs. You can open a single project for many po files and those
> graphs are also useful.
>
> I think we should give it a try. Do we start a pclos project then?
I like it a lot as well. I've installed Pootle on l10n.ipclinuxos.com for
testing purposes and now I'm working on putting SVN contents together.
SVN repo will have the structure advertised some time ago and I added another
Makefile feature yesterday: ability to merge .po and .pot files with upstream
.po and .pot files located somewhere on the disk.
As a base for SVN I'll use BerliOS CVS contents and then I'll merge files from
your tarball with it. Nothing should get lost during this process and our old
CVS msgstrs will take precedence.
Once the SVN is ready, I'll checkout parts of it (contents of each package's po
and desktop.in/po subdirectories) to Pootle data space, this will create
familiar "<gettext_domain>/*.po[t]" tree in Pootle.
Then the workflow will be as follows:
Anybody will be able to "suggest" translations via Pootle, some Pootle users
will have right to accept suggestions and directly translate Pootle .po files
and few (admin level) Pootle users will have right to commit Pootle data changes
to SVN. All can be done from Pootle web interface.
David
Alessio Adamo
As a base for SVN I'll use BerliOS CVS contents and then I'll merge files from
your tarball with it. Nothing should get lost during this process and our old
CVS msgstrs will take precedence.
I've already done this, there's no need to redo it. Maybe you could just check if everything is right. We should also take care of the header of those files. For instance the dutch files have no header and the po information refers to french team, french language and so on.
If you want redo it anyway, please don't with the italian and hungarian po files (the latter because I think I had a later version if compared to that in the CVS).
Once the SVN is ready, I'll checkout parts of it (contents of each package's po
and desktop.in/po subdirectories) to Pootle data space, this will create
familiar "<gettext_domain>/*.po[t]" tree in Pootle.
Then the workflow will be as follows:
Anybody will be able to "suggest" translations via Pootle, some Pootle users
will have right to accept suggestions and directly translate Pootle .po files
and few (admin level) Pootle users will have right to commit Pootle data changes
to SVN. All can be done from Pootle web interface.
David
Good plan of attack.
Alessio
Alessio Adamo
If we can reach this clear point of start, where all of the team could and should (re)arrange the lines.
Once we have set up everything my idea is to advertise ourselves in every national forum to gather new translating forces.
Pierre-Henri RAMBOZ
Envoyé de mon iPhone
Pierre-Henri RAMBOZ
Envoyé de mon iPhone
Alessio Adamo
The erroneous headers are quite often found but won't have any incidence on the end user. The translators m'au edit the po files related to theire team as part of the localisation workflow. So a bad header is not discriminent, but a bad encoding or a bad format may. Si despite the fact that you did it before, lets consider this not as an edit but a concistancy check from david! Doublecheck saves time, trust me. Berlios is a mess and i had no proofreader!
I agree, that's not priority at all. It's only a shame that for the Dutch team there's no translator's name (if I remember correctly) but maybe you remember and we can give him his credit.
I found a bad encoding or format in a Chinese po, for instance, and I've corrected it. As you said, it saves more time and it's less error-prone double-checking the work of others, instead of redoing it. I prefer David double-checking my work also because like that I know if I've made any mistakes and I can avoid them in the future.
For sure double-checking or even triple-checking must be our rule, if we want to gain the trust of developers.
Pierre-Henri RAMBOZ
Envoyé de mon iPhone
David Smid
>
>
> 2008/10/23 David Smid <da...@smidovi.eu>
>
>
> As a base for SVN I'll use BerliOS CVS contents and then I'll merge
> files from
> your tarball with it. Nothing should get lost during this process
> and our old
> CVS msgstrs will take precedence.
>
>
> I've already done this, there's no need to redo it. Maybe you could just
> check if everything is right. We should also take care of the header of
> those files. For instance the dutch files have no header and the po
> information refers to french team, french language and so on.
> If you want redo it anyway, please don't with the italian and hungarian
> po files (the latter because I think I had a later version if compared
> to that in the CVS).
I need to merge the .pot files anyway and if it works as expected, double
merging should cause no harm, so this can be a good test of the merge feature as
well. There's little work with that, it's just typing "make merge-with-upstream
UPSTREAM_DIR=xxx" in the root dir.
While creating the SVN contents, I've fixed two errors in Makefile.common and
I've added new optional parameters to the "new_package" script - now you can
specify alternative gettext domain(s) to enable copying of the right files from
BerliOS CVS repo:
./new-package drakxtools ../../pclos-i18n/CVSROOT/ libDrakX libDrakX-standalone
In the old BerliOS CVS, there are many translations that I am not sure about.
Which of them are obsolete or already included in upstream and shouldn't be
included in our SVN ?
David
---------------------------------
amarok
apt
aquamarine
aumix
bash
bluez-pin
command-not-found
compiz
coreutils
cpio
desktop_extragear-addons_kopete_skype
desktop_extragear-graphics_gwenview
desktop_extragear-multimedia_amarok
desktop_extragear-multimedia_k3b
desktop_extragear-network_kmldonkey
desktop_extragear-network_ktorrent
devede
dialog
diffutils
dvdrip
ekiga
emerald
error
fileutils
findutils
f-t
gettext-examples
gimp
gnome-desktop-2.0
gparted
gqview
grep
gst-plugins-base
gst-plugins
gstreamer
gtkam
gtk+
gtksourceview-1.0
gtkspell
gtk20
gtk20-properties
gutenprint
gwenview
chbg
id-utils
ion3
isomaster
iso_3166
iso_4217
iso_639
kaffeine
kalbum
kasablanca
katalog
kbluetoothdcm
kbluetoothd
kbtobexclient
kbtsearch
kbtserialchat
kbudget
kcmfonts
kcmkicker
kcmlaptop
kcmtaskbar
kdmconfig
kdmgreet
kfile_k3b
kfile_palm
khciconfig
kicker
kima
kioclient
kio_videodvd
klinkstatus
kmplayer
kommander
kose
konserve
koverartist
kover
krozat
krusader
ksplash
kssh
ktorrent
kwin_clients
kxsldbg
k3b
k3bsetup
leafpad
libgpewidget
libkbluetooth
libk3bdevice
libk3b
liveusb
lynx
mkremaster
mplayerplug-in
mplayer
nano
psmisc
pwmanager
quanta
redo-mbr
rpm
sed
shared-mime-info
sh-utils
smart
smb4k
soundconverter
soundkonverte
soundkonverter
streamripper
streamtuner
system-tools-backends
tar
textutils
tightvnc
tomboy
tuxpaint
tvtime
wdiff
wget
xchat
xkeyboard-config
xpad
xsane
yakuake
Zoltan Hoppar
Pierre-Henri RAMBOZ
Envoyé de mon iPhone
Le 23 oct. 08 à 16:17, David Smid <da...@smidovi.eu> a écrit :
David Smid
> Unfortunarely we will have to check against the srpms to be sure
>
>> In the old BerliOS CVS, there are many translations that I am not
>> sure about.
>> Which of them are obsolete or already included in upstream and
>> shouldn't be
>> included in our SVN ?
>>
>> David
Here is a better list sorted by count of translations.
My opinion is, that parts of KDE or GNOME should not be in our SVN as their
upstream translation is usually high quality and PCLOS does not patch them
heavily. However, there can be exceptions when reasonable.
None of the following translations will be included in SVN unless suggested by
any project member.
For now, I suggest adding:
apt (incomplete upstream translation)
kicker (KICKOFF patches)
ksplash ("Welcome to" message l10n)
redo-mbr (PCLOS core)
rpm (incomplete upstream translation)
mkremaster (PCLOS core)
command-not-found (PCLOS core)
David
--------------------------------------------------------
1 bash hu
1 bluez-pin hu
1 coreutils hu
1 cpio hu
1 desktop_extragear-addons_kopete_skype hu
1 desktop_extragear-graphics_gwenview hu
1 desktop_extragear-multimedia_amarok hu
1 desktop_extragear-multimedia_k3b hu
1 desktop_extragear-network_kmldonkey hu
1 desktop_extragear-network_ktorrent hu
1 dialog hu
1 diffutils hu
1 dvdrip fr
1 ekiga hu
1 error hu
1 fileutils hu
1 findutils hu
1 f-spot hu
1 gettext-examples hu
1 gimp hu
1 gnome-desktop-2.0 fr
1 gparted hu
1 gqview hu
1 grep hu
1 gst-plugins-base hu
1 gst-plugins hu
1 gstreamer hu
1 gtkam hu
1 gtk+ fr
1 gtksourceview-1.0 fr
1 gtkspell fr
1 gtk20 fr
1 gtk20-properties fr
1 gutenprint hu
1 gwenview hu
1 chbg fr
1 id-utils hu
1 isomaster hu
1 iso_3166 hu
1 iso_4217 hu
1 iso_639 hu
1 kalbum hu
1 kasablanca hu
1 katalog hu
1 kbluetoothdcm hu
1 kbluetoothd hu
1 kbtobexclient hu
1 kbtsearch hu
1 kbtserialchat hu
1 kcmkicker cs
1 kcmtaskbar fr
1 kfile_k3b hu
1 kfile_palm hu
1 khciconfig hu
1 kicker cs
1 kima hu
1 kioclient hu
1 kio_videodvd hu
1 klinkstatus hu
1 kommander hu
1 koverartist hu
1 kover hu
1 krozat hu
1 krusader hu
1 ksplash cs
1 kssh fr
1 ktorrent fr
1 kwin_clients fr
1 kxsldbg hu
1 leafpad hu
1 libgpewidget hu
1 libkbluetooth hu
1 lynx hu
1 mplayer fr
1 mplayerplug-in hu
1 nano hu
1 psmisc hu
1 pwmanager hu
1 quanta hu
1 redo-mbr it
1 rpm cs
1 sed hu
1 shared-mime-info hu
1 sh-utils hu
1 smart fr
1 smb4k hu
1 soundkonverte nl
1 streamripper hu
1 streamtuner hu
1 system-tools-backends hu
1 tar hu
1 textutils hu
1 tomboy hu
1 tuxpaint hu
1 tvtime hu
1 wdiff hu
1 wget hu
1 xchat hu
1 xkeyboard-config hu
1 xpad hu
1 yakuake hu
2 amarok fr hu
2 kbudget fr nl
2 kcmfonts fr hu
2 kcmlaptop fr hu
2 kdmconfig fr hu
2 kmplayer cs hu
2 liveusb it hu
2 mkremaster it hu
2 soundconverter fr nl
3 aumix fr nl pl
3 command-not-found fr it cs
3 emerald fr nl pl
3 ion3 fr fi cs
3 kaffeine fr nl hu
3 kdmgreet fr pl hu
3 konserve fr nl pl
3 xsane fr nl hu
4 aquamarine fr nl pl hu
4 compiz fr nl pl hu
4 devede fr nl pl hu
4 soundkonverter fr de pl hu
5 k3b es fr nl pl hu
5 k3bsetup es fr nl pl hu
5 libk3bdevice es fr nl pl hu
5 libk3b es fr nl pl hu
6 tightvnc fr it nl pl sl hu
7 apt pt_BR es de it ru cs ja
Pierre-Henri RAMBOZ
What about pclos community requests?
Do we ignore them or do we send those to the package developers and
pray for inclusion and wait for pclos package upgrade?
Envoyé de mon iPhone
Le 24 oct. 08 à 11:38, David Smid <da...@smidovi.eu> a écrit :
Pierre-Henri RAMBOZ
still be the best.
Envoyé de mon iPhone
Le 24 oct. 08 à 11:38, David Smid <da...@smidovi.eu> a écrit :
Alessio Adamo
Pierre-Henri RAMBOZ
We need a policy, not an opinion. If we translate apt why not any
other software?
My very opinion is that we should focuss on core packages and then
extend to additional soft then mirror with software project for the
very reason that we as a team working system wide are more efficient
than a few fans working on some obscure soft.
This isn't our primary rôle but that is the way other teams work!
Check the headers files in po and you will see that.
Lets not focus on that but not forget
Envoyé de mon iPhone
Le 26 oct. 08 à 00:54, "Alessio Adamo" <alessi...@gmail.com> a
écrit :
David Šmíd
But there are other legacy translations and we must decide how to deal with them.
There are three sorts of translations:
1) Translations of core PCLOS packages that are not maintained elsewhere. This is our "raison d'être".
2) Translations of packages incompletely translated upstream. I believe we should maintain them too (only those important to PCLOS overall functionality -> therefore I suggested apt). But we should push our translations upstream as soon as possible and once the upstream accepts our commits, we should no longer maintain them. Of course definition of "important to PCLOS" can change in time.
3) Translations of packages incompletely translated upstream and not important in PCLOS. We should rely on upstream to translate them or to send our translations directly upstream. We should not maintain them.
4) Translations of packages completely translated upstream. No reason to maintain them. I believe many translations in old BerliOS CVS were just ripped from upstream packages.
Pierre-Henri RAMBOZ
Envoyé de mon iPhone
Alessio Adamo
PS. I had a look at mandvd and it's rubbish on the i18n point of view. It even doesn't use po files. A project could be make it po-friendly. But it should be a side project.
Pierre-Henri RAMBOZ
Envoyé de mon iPhone
Alessio Adamo
Recheck mandvd
I won't go further on this because I don't want to drift the discussion to other lands, but in the pclos rpm there re no po files and the same is true for the original source
http://www.kde-apps.org/content/show.php/ManDVD?content=83906
For translation the developer asks you to translate the lang.h file (which assigns messages to an array of constants) which is not even utf8-encoded.
Maybe it supports po files but the developer doesn't know since the actual one took over Gibault Stéphane who was not maintaining anymore.
Ramboz Pierre-Henri
2 : about my way of adressing to people.
i tend not to be impolite but i won't excessively pay attention to one's susceptibility. i assume that the people i'm discussing with are cleaver and take the time to backup and illustrate theyre statements. if they don't, i consider it's not my role to tell them they should. I know that time will compensate this lack of individual action and research. in an opensource project, when we work remotely, we need to read and answer carefully. and forget about individual feelings and moods. my previous post were trying to arise the non pocentered localization and soon the documentation translation. and its related to this post because its part of what we are trying to achieve... a lots of pclinuxos centric files are not gettext compliant either... and those are not in our list !
so please keep your personal comment for you as i keep mine private. we need to concentrate on the topic.
my very question is : do we add gettext support to the apps (within pclinuxos and eventually out of it) when those don't support po framework or do we work in the original framework if there is one ?
3 : methodology tends to drag discussion and schematics from global to local issues... so lets first draw a ide plan before narrowing on po related to pclinuxos and that yet doesexist or when we will have to deal with software that are critical to the os or the community ... we will be a pain in the ass as the clan can be when it strips localization from RPM ... So lets think global, act local and enjoy what is opensource... we yet need a policy but we also need a plan of action or we won't be reactive. this isn't politics and i'm not trying to please anyone in this talk. lets just do it like pro and not forget that this project should last several years...
Alessio Adamo
What pclos needs is translation of its own core packages. mandvd or any other untranslated external software does not affect the distro appeal. Having half system in english and half in native language does. Since we are a tiny group we should stay focused on our main aim. Nothing forbids anyone of us to start or to join other localisation projects for software we like the most.
Just my point of view.
Pierre-Henri RAMBOZ
I didn't say mandvd is not localisable, I said it is, but in a rubbish way. That's my opinion. Full stop. I didn't say anything less, anything more, anything else between the lines.
What pclos needs is translation of its own core packages. mandvd or any other untranslated external software does not affect the distro appeal.
Having half system in english and half in native language does. Since we are a tiny group we should stay focused on our main aim.
Nothing forbids anyone of us to start or to join other localisation projects for software we like the most.
Just my point of view
Alessio Adamo
In the case there is no xyz-i18n project running yet, having a separated project with the developer's blessing makes it easier to get collaborators who otherwise would't be attracted by the pclos-i18n project. Nothing forbids a link from within the pclos-i18n front page, but that doesn't mean that the language team leaders and members have to be the same, for instance.
It would be very commendable helping external developers (who maybe have no time or no means) get a i18n project running for their own piece of software; instead, running a separated project when there is already an external one would look sectarian.
I suggest starting with the core packages and see how it goes. Then we can decide enlarge our field of action. Don't you agree?
Alessio Adamo
Are there any issues you still need to solve? If yes, what?
Just a tiny progress report...
Ramboz Pierre-Henri
I agree it's a valuable thing to have such good pieces of software translated (or even translatable in some cases), but that goes and has to go beyond the limits of pclos. There can be many people out there who don't give a damn about pclos but would be very interested in having xyz translatable/translated. Maybe there is already someone working on it. Therefore it would be a waste of efforts to have someone doing it within the pclos project and someone else from outside. It would be better to join the forces. (This attitude would also fit more with the open-community spirit). Both pclinuxers and non-pclinuxers will then make use of it
In the case there is no xyz-i18n project running yet, having a separated project with the developer's blessing makes it easier to get collaborators who otherwise would't be attracted by the pclos-i18n project. Nothing forbids a link from within the pclos-i18n front page, but that doesn't mean that the language team leaders and members have to be the same, for instance.
It would be very commendable helping external developers (who maybe have no time or no means) get a i18n project running for their own piece of software; instead, running a separated project when there is already an external one would look sectarian.
I suggest starting with the core packages and see how it goes. Then we can decide enlarge our field of action. Don't you agree?
i yet told you i did ...
but it is not a matter of translation... lets open the topic and not narrow it ... its just a discussion and not yet an asset.
the point is ... how do we handle the rest of the software ? (no the core)
when the project started, french and hungarian team not only worked on translation bt keymapping and boot séquence aswell as missing po hunt ... we extracted those missing po from mandy srpms and tarballs ... devs still don't include all translation... so do we repackage those rpms with the missing part and separate the localization files as dependent rpms or do we reinput those straight in mainstream by force (which is pointless) or do we keep ignoring them ?
what about those software that noone translated? If we checked and found noone working on the translation... can we act as a "hub" for traslation and build them in team then forward to the software's mainstream ? isn't it revealant with the pre/post svn scheme you described alessio?
Once again ... pclinuxos in itself is not a limit in this project, its rather an objective ... i think we can be more and attract more people working as a hub by providing translation when needed rather than when it is pclinuxos ... yes the core packages are priority but can't we add po support to "foo" software and translate "bar" software in the pclinuxos-i18n team, based on request from community, rather than letting gr8 and usefull software fall into the shadows due to its anglophonia ?
isn't it the same as what the dev do when they don't include our work into the cvs ? isn't santa the best improvement in 3rd party software release for pclinuxos? Should textar have just used mandy rpms without repacking them and rewriting the specs? Why are his specs pretty often release with sources of some packages ?
i think we can't REJECT the option of doing it from within ... but it must not be the first opbjective nevertheless it must be featured in the description of our work ... since i do believe its a duty that we have towards the user ...
my personnal feeling and desire are not laws and i can understand that we don't agree on this but i would like to read your (all of you) very opinion on this! Can we just do the core ... and if not .. why apt? Are we just translators or localizers ? is localization a matter of pclinuxs software translation only for it sounds like it is since the last two weeks?
DidouPh
Ramboz Pierre-Henri
" i can give you a machinegun and tell you to dance with it ... you won't be able to advertise for Bentley !"
btw ... david gave us quite a concise but yet revealent answer a the previous question :
1) Translations of core PCLOS packages that are not maintained elsewhere. This is our "raison d'être".
2) Translations of packages incompletely translated upstream. I believe we should maintain them too (only those important to PCLOS overall functionality -> therefore I suggested apt). But we should push our translations upstream as soon as possible and once the upstream accepts our commits, we should no longer maintain them. Of course definition of "important to PCLOS" can change in time.
3) Translations of packages incompletely translated upstream and not important in PCLOS. We should rely on upstream to translate them or to send our translations directly upstream. We should not maintain them.
4) Translations of packages completely translated upstream. No reason to maintain them. I believe many translations in old BerliOS CVS were just ripped from upstream packages.
Alessio Adamo
shouldn't we know what we are going to do before advertising and jumping on tools ...
Well, we decided how to organize our work already and once the system is set we'll be able to work at our highest priority task (=translating the core packages and implement i18n in core packages which do not support it yet; ie. draklive-install, mkliveusb, mkremaster, official kde splash, kdm official theme, redo-mbr, pclos-mime).
I've already repackaged draklive-install and pclos-mime. I'm going to finish redo-mbr and I've started mkliveusb and mkremaster (which are within the mklivecd package). The other two are not difficult, but it's better to wait until the rc is out.
The rest can be added in a second time, eventually.
The only point not endavoured is the one related to the packge exclded from rpm by the gang during the built process!
You know, I didn't know that something so short-sighted was done. And from wherever I look at it, I can't fine any credible reason.
PS. Can you tell me in few words the Synaptic story? I joined too late to know about it.
Ramboz Pierre-Henri
2008/10/26 Ramboz Pierre-Henri <did...@gmail.com>shouldn't we know what we are going to do before advertising and jumping on tools ...
Well, we decided how to organize our work already and once the system is set we'll be able to work at our highest priority task (=translating the core packages and implement i18n in core packages which do not support it yet; ie. draklive-install, mkliveusb, mkremaster, official kde splash, kdm official theme, redo-mbr, pclos-mime).
i ment ... do you know what is in the iso to be released ?
we (you) may yet have something to do but we ned apointment and a real roadmap on the assets that we have met and the objectives we have ... precise and concise ...
I've already repackaged draklive-install and pclos-mime. I'm going to finish redo-mbr and I've started mkliveusb and mkremaster (which are within the mklivecd package). The other two are not difficult, but it's better to wait until the rc is out.
sounds like this answers to the above !
The rest can be added in a second time, eventually.
The only point not endavoured is the one related to the packge exclded from rpm by the gang during the built process!
You know, I didn't know that something so short-sighted was done. And from wherever I look at it, I can't fine any credible reason.
PS. Can you tell me in few words the Synaptic story? I joined too late to know about it.
Alessio Adamo
i ment ... do you know what is in the iso to be released ?
we (you) may yet have something to do but we ned apointment and a real roadmap on the assets that we have met and the objectives we have ... precise and concise ...
Yes, but I meant... We decided more or less how to organize our work. We know the name of at least some of the packages which will be for sure in the distro core. Let's start pushing them. Unless there are technical reasons which prevent doing it at the moment. Just for sake of curiosity I'd like to know what's going on.
what is the rest ?
we all guessed that it was related to space rather than "evil" ... pclos is a remaster ... it must be stripped to the bones to be efficient ... so a strip from within the rpms and a plan to reimplement the "locale" package was indeed an accurate idea ... and the best choice to make but nfortunately most translation never got back from sources to repo...
I doubt it because the iso has installed packages and when you install a package only the mo file which matches the system language is installed, no matter how many you have in that package. That's why you need to reinstall the package to have it localized after a modification of the system language setting. Am I wrong?
So the only reason I can find is to keep the size of the repo small. Hard to believe, so I think and hope there must have been another reason.
PS. Can you tell me in few words the Synaptic story? I joined too late to know about it.
synaptic has been heavily adapted to pclinuxos ... at the biggining it was not fully i18n compliant for the reason that both the pot and po had not been updated for ages ... our synaptic is based on a non mainstream version so we had first to find out and add the missing strings to the po, hten hack into synaptic to allow category translation for users to search in software database more efficiently ... it was the first collaboration with santa and a major asset from our team for pclinuxos ... a large amount of job from gettinther on that and a fast and efficient work from all the team got the ob done in about 2 weeks ... the problem is that some packagers put "fancy" category that weren't adde to our pot and we never even got a litle "thumb" up from thegang for that ... a few weeks later ... i 18n team had lost about 50% of its member, including my belgian collaborator and co leader dubi (disgusted from the way things got done) that's when the project almost stalled and you apeared about 2/3 weeks later ... (if i remember well) dubi was still active but from far ...
Ramboz Pierre-Henri
2008/10/27 Ramboz Pierre-Henri <did...@gmail.com>i ment ... do you know what is in the iso to be released ?
we (you) may yet have something to do but we ned apointment and a real roadmap on the assets that we have met and the objectives we have ... precise and concise ...
Yes, but I meant... We decided more or less how to organize our work. We know the name of at least some of the packages which will be for sure in the distro core. Let's start pushing them. Unless there are technical reasons which prevent doing it at the moment. Just for sake of curiosity I'd like to know what's going on.
what is the rest ?Other non-core packages, for instance those we were discussing above.
we all guessed that it was related to space rather than "evil" ... pclos is a remaster ... it must be stripped to the bones to be efficient ... so a strip from within the rpms and a plan to reimplement the "locale" package was indeed an accurate idea ... and the best choice to make but nfortunately most translation never got back from sources to repo...
I doubt it because the iso has installed packages and when you install a package only the mo file which matches the system language is installed, no matter how many you have in that package. That's why you need to reinstall the package to have it localized after a modification of the system language setting. Am I wrong?
So the only reason I can find is to keep the size of the repo small. Hard to believe, so I think and hope there must have been another reason.
David Smid
Let's start with the core packages, then we can continually add more and
more less important packages.
For me, the importance of package localization is measured by
probability that its untranslated messages will hit eyes of common user.
Therefore adding msgid "Welcome to" to ksplash.po is very important for me.
Anyway, let's not hunt too many hares in the same time. The other
translations can peacefully rest in the BerliOS CVS until we pick them
up once we don't have anything to do.
I am not against adding any translation suggested by you or the community.
Progress report:
Core packages have their entries ready, I must check all the original
translations, correct fatal mistakes, merge the result with Alessio's
tarball, add .desktop files where applicable and the SVN is ready.
On Wednesday I will be reinstalling OS on server that hosts our Pootle
installation (stability issues) and then I can check out translations to
Pootle. Then I will have to add some user accounts to Pootle, set the
rights and then you can start translating.
I'm fully occupied with my family right now, because it's holiday today
and tomorrow here in the Czech Rep.
David
Alessio Adamo
Pierre-Henri RAMBOZ
Envoyé de mon iPhone