Debian Installer Manual Translations (was: repository branched for sarge)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (please keep both d-boot and d-i18n CC'ed for this discussion) On Tuesday 30 November 2004 06:52, Christian Perrier wrote: In my opinion, that counts first for changes to the original version of the manual. However, as soon as some English is changed in the manual, there's of course no permission to request for updating translations. Frans, do you agree with that interpretation? To be honest I'm not sure how the manual should be maintained after the branching. Maybe we should discuss our options; I'll give a start below. Comments very welcome. For the English original I feel that for the time being most changes in trunk could safely go to the Sarge branch: there are plenty of improvements possible that are relevant for Sarge, including the planned reorganization of Chapter 2 (which I plan to start this weekend). I would not like to discourage changes relevant for Sarge by focussing on post-Sarge too soon and IMHO maintaining two versions is way to complicated and too much work (which would discourage work on the manual even more). The only changes to the manual that should not go into the Sarge branch would be those relating to post-sarge development, like localechooser. I would suggest we postpone making these changes for the time being In some cases, we could even consider documenting both the old and new way d-i works by adding notes. Translations that have been officially included (es, fr, ja, pt_BR, sp) === For these any changes made in the Sarge branch in the English docs should preferably be translated as well. If translations are out-of-date (like pt_BR currently), I guess it would be good update these in both branches. All other translations == These are only shown on the d-i manual website. As these translations are build from trunk, I see no advantage in updating these translations in the Sarge branch, as there would be risks in including extra translations on the CD's in later builds. In fact, it would probably be safer to delete these languages in the Sarge branch. At some future time, when d-i really starts to diverge from it's Sarge version, this proposed policy should of course be reconsidered. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBrd8Vgm/Kwh6ICoQRAsmvAKDS9EthIFmJmlGGY2RIocv9x3h2/wCfYcIB dj9C3l/HIDBaeaq/RU1EARU= =p9gG -END PGP SIGNATURE-
Re: Debian Installer Manual Translations (was: repository branched for sarge)
Hi, All other translations == These are only shown on the d-i manual website. As these translations are build from trunk, I see no advantage in updating these translations in the Sarge branch, as there would be risks in including extra translations on the CD's in later builds. In fact, it would probably be safer to delete these languages in the Sarge branch. So it isn't possible to get a german version on the CD anymore? :-( Greetings Holger -- == Created with Sylpheed-Claws 0.9.12 under Debian GNU LINUX 3.1 Sarge (testing). http://counter.li.org/ Registered LinuxUser #311290 Spamfiltering powered by www.spamassassin.org = -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Installer Manual Translations (was: repository branched for sarge)
For the English original I feel that for the time being most changes in trunk could safely go to the Sarge branch: there are plenty of improvements possible that are relevant for Sarge, including the planned reorganization of Chapter 2 (which I plan to start this weekend). I would not like to discourage changes relevant for Sarge by focussing on post-Sarge too soon and IMHO maintaining two versions is way to complicated and too much work (which would discourage work on the manual even more). The only changes to the manual that should not go into the Sarge branch would be those relating to post-sarge development, like localechooser. I fully agree with that view (and *not* only because this allows me to avoid writing documentation for localechooser). There is no urgent need for updates relevant to new material as we will probably be still focused on the sarge version for some time after the release of no-name-yet. All other translations == These are only shown on the d-i manual website. As these translations are build from trunk, I see no advantage in updating these translations in the Sarge branch, as there would be risks in including extra translations on the CD's in later builds. In fact, it would probably be safer to delete these languages in the Sarge branch. Supported as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Installer Manual Translations (was: repository branched for sarge)
On Wed, Dec 01, 2004 at 04:11:07PM +0100, Frans Pop wrote: Translations that have been officially included (es, fr, ja, pt_BR, sp) sp? === For these any changes made in the Sarge branch in the English docs should preferably be translated as well. If translations are out-of-date (like pt_BR currently), I guess it would be good update these in both branches. All other translations == These are only shown on the d-i manual website. As these translations are build from trunk, I see no advantage in updating these translations in the Sarge branch, as there would be risks in including extra translations on the CD's in later builds. In fact, it would probably be safer to delete these languages in the Sarge branch. But the install manual used on the official Debian website will surely be built from the sarge branch when the time comes; even if these languages don't make it onto the CDs, we'd just have to add them back to the sarge branch later for the website maintenance, no? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: repository branched for sarge
Hi, I'd go further and consider getting all patches for the sarge branch tested in trunk and/or reviewed by this list before committing them there. Sorry: I assume this also counts for translations of the manual? In my opinion, that counts first for changes to the original version of the manual. However, as soon as some English is changed in the manual, there's of course no permission to request for updating translations. ??? So from now on the translations have to leave as they are? I think it's only a translation, no changing in context/sense and not bothering the d-i code. One should use the time remaining till the sarge release, but I will do as ordered... Frans, do you agree with that interpretation? Greetings Holger -- == Created with Sylpheed-Claws 0.9.12 under Debian GNU LINUX 3.1 Sarge (testing). http://counter.li.org/ Registered LinuxUser #311290 Spamfiltering powered by www.spamassassin.org = -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: repository branched for sarge
Quoting Holger Wansing ([EMAIL PROTECTED]): In my opinion, that counts first for changes to the original version of the manual. However, as soon as some English is changed in the manual, there's of course no permission to request for updating translations. ??? So from now on the translations have to leave as they are? Looks like my sentence wasn't clear. I was more focused on English version than translations when replying. IMHO, you do not need asking for updating translations in the sarge branch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: repository branched for sarge
Hi, Looks like my sentence wasn't clear. I was more focused on English version than translations when replying. IMHO, you do not need asking for updating translations in the sarge branch. OK. I will commit the changed files first to trunk and when it is built there with no errors, then commit them to sarge, too (as long as the original is the same, of course) Thanks Holger -- == Created with Sylpheed-Claws 0.9.12 under Debian GNU LINUX 3.1 Sarge (testing). http://counter.li.org/ Registered LinuxUser #311290 Spamfiltering powered by www.spamassassin.org = -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: repository branched for sarge
Hi, So, the best, IMHO, is currently considering that the sarge branch is still under a deep string freeze. I'd go further and consider getting all patches for the sarge branch tested in trunk and/or reviewed by this list before committing them there. Sorry: I assume this also counts for translations of the manual? Greets Holger -- == Created with Sylpheed-Claws 0.9.12 under Debian GNU LINUX 3.1 Sarge (testing). http://counter.li.org/ Registered LinuxUser #311290 Spamfiltering powered by www.spamassassin.org = -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: repository branched for sarge
Quoting Holger Wansing ([EMAIL PROTECTED]): Sorry: I assume this also counts for translations of the manual? In my opinion, that counts first for changes to the original version of the manual. However, as soon as some English is changed in the manual, there's of course no permission to request for updating translations. Frans, do you agree with that interpretation? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [IMPORTANT] (forw) Debian Installer repository branched for sarge
Hi, At Sat, 27 Nov 2004 19:13:08 +0100, Christian Perrier wrote: Translators of Debian Installer, this is VERY important. From now, you will have to handle level 1 translations in TWO branches of the d-i repository. The sarge branch will probably be frozen enough for you not caring that much of it and only focus on changes in the unstable branch. We will however very probably setup two parallel infrastructures: -I will setup one for l10n-sync to run on both branches -Dennis will setup one for statistics on each branch. Please note that all this has just been announced and thus we need to arrange things and organize the while stuff. So, please be patient as well When we want to update installer/doc/manual, what's the best way for two branches? Thanks, -- Kenshi Muto [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [IMPORTANT] (forw) Debian Installer repository branched for sarge
When we want to update installer/doc/manual, what's the best way for two branches? Well, it's up to us to decide..:-) My first opinion is that we have to mantain two branches of the manual as well: -the sarge branch only receives few updates in the original manual. The translators should first focus on it when their language is not complete yet -the trunk branch will receive new contributions. Translators should work on it only when sarge is complete for their language. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
repository branched for sarge
I've added a branch for sarge in the d-i repository, based on the current trunk. The uri is: svn+ssh://svn.debian.org/svn/d-i/branches/d-i/sarge Changes to fix rc2 errata-type problems should be made there as well as in trunk, and for now it seems best to upload them to unstable and talk to me about getting them into testing. So trunk is now open for post-sarge changes. However it's still not known where post-sarge udebs will be uploaded to at this point, or how images will be put together to test them. Adding too many untested changes to trunk could be bad as we might have to spend a lot of time later getting things back into a good working state. So please continue to be slighlty conservative there, or spend some of your energy on working out how to get your larger changes tested and on setting up the infrastructure for that. -- see shy jo signature.asc Description: Digital signature
Re: repository branched for sarge
Quoting Joey Hess ([EMAIL PROTECTED]): I've added a branch for sarge in the d-i repository, based on the current trunk. The uri is: svn+ssh://svn.debian.org/svn/d-i/branches/d-i/sarge Changes to fix rc2 errata-type problems should be made there as well as in trunk, and for now it seems best to upload them to unstable and talk to me about getting them into testing. I strongly ask to all D-I developers to avoid string changes in the sarge branch. Please talk to me before doing so as this will need special care for handling translation updates. The i18n/l10n team needs to organize stuff for handling the branching : -I need to setup l10n-sync for running on each branch -Dennis needs to setup a statistics infrastructure for the sarge branch So, the best, IMHO, is currently considering that the sarge branch is still under a deep string freeze. I have mailed the translators about the branching (some do not follow -boot) but several of them may be confused by the branching, so please be kind with them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: repository branched for sarge
Christian Perrier wrote: I strongly ask to all D-I developers to avoid string changes in the sarge branch. Please talk to me before doing so as this will need special care for handling translation updates. The i18n/l10n team needs to organize stuff for handling the branching : -I need to setup l10n-sync for running on each branch -Dennis needs to setup a statistics infrastructure for the sarge branch So, the best, IMHO, is currently considering that the sarge branch is still under a deep string freeze. I'd go further and consider getting all patches for the sarge branch tested in trunk and/or reviewed by this list before committing them there. -- see shy jo signature.asc Description: Digital signature
Re: Branched languagechooser
Christian Perrier wrote: No, the code is not optimal at all. The sourcing is copied from languagechooser as well as the program being a standalone program. Clean code is far from being my best quality, even for sheel scripts, which are the only ones I'm really able to write. So, making all this cleaner is really needed, but I would appreciate if someone does it : otherwise, I would lose a lot of time trying to do so, without real efficiency. So, I will currently only fix the errors aboveat least for today. I've done some cleanup.. I don't understand the use of COUNTRYCODE_LANGUAGECHOOSER. It seems that is the selected country is the same as the default country as set in this variable, then LOCALE will not be set, and debian-installer/locale will be set to . Is there a reason to have countrychooser/default-country? Nothing currently uses it. -- see shy jo signature.asc Description: Digital signature
Re: Branched languagechooser
Quoting Joey Hess ([EMAIL PROTECTED]): I gave it a try. I really like the new language chooser, it feels clean and simple. I don't know whether the country codes on the left column (and especially the C) will puzzle users who are not familiar with that convention. This came from some threads here about how to sort the screen. The conclusion I had was using the ISO codes. The one who suggested this (no more idea who it was) just mentioned that this way, users will have little more chance to know their own country code. The C is a trick. I wanted to keep English at the top of the list, so using the default locale convention was a good way to do this. This may be a bit confusing as this does not trigger the C locale but indeed en as language code and US as default country (before countrychooser) countrychooser does not support backing up, and if I choose English, I get Andorra as a default country, which is not the best default. If I hit u for US, it goes down one line the the UAE. I hit it again and it jumped all the way down to the rest of the u's. Minor outlying islands of the US are listed before the main country. For some reason, after choosing United States, kbd-chooser defaulted me to a Bulgarian keyboard. Why? Well, in the shell, debconf-get debian-installer/country says UM. Not US. I'm sure I did not pick the outlying islands; I went back and tried it again and still got UM. Probably a substring match bug. Of course I doubt that residents of the Midway Islands use Bulgarian keyboards either.. ;-) There is some bad coding there, as far as I have seen while testing. I wanted to clean this up a bit yesterday but some discussions about timezones as wellas several contacts with translators prevented me to do so. In the code: Is sourcing these countrycodemap, countrymap, programs really necessary? I would write these as subroutines. It would also save space to move the countrychooser program into the package's postinst. No, the code is not optimal at all. The sourcing is copied from languagechooser as well as the program being a standalone program. Clean code is far from being my best quality, even for sheel scripts, which are the only ones I'm really able to write. So, making all this cleaner is really needed, but I would appreciate if someone does it : otherwise, I would lose a lot of time trying to do so, without real efficiency. So, I will currently only fix the errors aboveat least for today. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Branched languagechooser
As some of you may have noticed, and as suggested by Joey and Steve Langasek, I created a languagechooser_ng branch in languagechooser (I did so two days ago but forgot to announce it here). This will allow those who want to test out my languagechooser proposal along with the new countrychooser to give them a look. May someone explain me how I can merge in possible changes made to languagechooser HEAD into the languagechooser_ng branch? As I already told, my CVS knowledge is a bit crude and empiric..:-) For instance, I stupidely made my branching on some versions of files other than those who were in CVS at the moment I branched out. The changes were easy to manually merge in, however -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Branched languagechooser
Christian Perrier wrote: As some of you may have noticed, and as suggested by Joey and Steve Langasek, I created a languagechooser_ng branch in languagechooser (I did so two days ago but forgot to announce it here). This will allow those who want to test out my languagechooser proposal along with the new countrychooser to give them a look. I gave it a try. I really like the new language chooser, it feels clean and simple. I don't know whether the country codes on the left column (and especially the C) will puzzle users who are not familiar with that convention. countrychooser does not support backing up, and if I choose English, I get Andorra as a default country, which is not the best default. If I hit u for US, it goes down one line the the UAE. I hit it again and it jumped all the way down to the rest of the u's. Minor outlying islands of the US are listed before the main country. For some reason, after choosing United States, kbd-chooser defaulted me to a Bulgarian keyboard. Why? Well, in the shell, debconf-get debian-installer/country says UM. Not US. I'm sure I did not pick the outlying islands; I went back and tried it again and still got UM. Probably a substring match bug. Of course I doubt that residents of the Midway Islands use Bulgarian keyboards either.. ;-) In the code: Is sourcing these countrycodemap, countrymap, programs really necessary? I would write these as subroutines. It would also save space to move the countrychooser program into the package's postinst. -- see shy jo signature.asc Description: Digital signature
Re: branched
Quoting Joey Hess ([EMAIL PROTECTED]): The branch is set up, it's called beta2, so cvs update -r beta2 to switch a tree over to it, etc. So this means that cvs head is open for random development not targeted at beta 2. So, this means that we can commit translation minor fixes to beta-2? Or maybe should be commit them to both branches? Example: #226293 fix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: branched
Christian Perrier wrote: Quoting Joey Hess ([EMAIL PROTECTED]): The branch is set up, it's called beta2, so cvs update -r beta2 to switch a tree over to it, etc. So this means that cvs head is open for random development not targeted at beta 2. So, this means that we can commit translation minor fixes to beta-2? Or maybe should be commit them to both branches? Example: #226293 fix You're welcome to try, but it's highly unlikely it would get in, unless the package was puched into beta 2 for some other good reason. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: branched
[Joey Hess] The branch is set up, it's called beta2, so cvs update -r beta2 to switch a tree over to it, etc. So this means that cvs head is open for random development not targeted at beta 2. Do we upload from the branch or from the trunk? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: branched
Petter Reinholdtsen wrote: [Joey Hess] The branch is set up, it's called beta2, so cvs update -r beta2 to switch a tree over to it, etc. So this means that cvs head is open for random development not targeted at beta 2. Do we upload from the branch or from the trunk? If it's random development not targeted at beta 2, to the trunk. -- see shy jo signature.asc Description: Digital signature
Re: branched
At 5 Jan 04 23:37:43 GMT, Joey Hess wrote: Or maybe should be commit them to both branches? Example: #226293 fix You're welcome to try, but it's highly unlikely it would get in, unless the package was puched into beta 2 for some other good reason. Hmm, how to solve changelog conflict? I'd like to modify base-installer.postinst for next beta (not for beta2). (off topic: Could you commit your change to base-config CVS, Joey?) -- Kenshi Muto [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: branched
Kenshi Muto wrote: Hmm, how to solve changelog conflict? I'd like to modify base-installer.postinst for next beta (not for beta2). Commit as usual (although, I have a greatly changed version of that file I hope to commit soon.) If we need to update base-installer for beta 2, we will use a special version number of some kind. (off topic: Could you commit your change to base-config CVS, Joey?) When I have more outgoing bandwidth than 4800 baud. (This is not an exaggeration.) -- see shy jo signature.asc Description: Digital signature
Re: branched
On Mon, Jan 05, 2004 at 08:01:43PM -0500, Joey Hess wrote: Petter Reinholdtsen wrote: [Joey Hess] The branch is set up, it's called beta2, so cvs update -r beta2 to switch a tree over to it, etc. So this means that cvs head is open for random development not targeted at beta 2. Do we upload from the branch or from the trunk? If it's random development not targeted at beta 2, to the trunk. So to recap and make sure I understand this correctly: - Normal development takes place on the trunk. - Changes required for beta2 (presumably for one of the ports) are made on the branch as well. - Uploads to unstable of d-i packages should come from the beta2 branch only. - When a port is considered a viable beta candidate, it will be frozen into testing along with i386. (Will i386 also get a pulse from unstable at this time, or will we lose the ability to rebuild all of testing from source during this freeze?) - When the music stops, those ports that have d-i candidates in testing will be released as beta2. Is that right? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: branched
Steve Langasek wrote: So to recap and make sure I understand this correctly: - Normal development takes place on the trunk. - Changes required for beta2 (presumably for one of the ports) are made on the branch as well. - Uploads to unstable of d-i packages should come from the beta2 branch only. - When a port is considered a viable beta candidate, it will be frozen into testing along with i386. (Will i386 also get a pulse from unstable at this time, or will we lose the ability to rebuild all of testing from source during this freeze?) I'm going to try to limit the changes to i386 in testing, so if I can force in an architecture dependant package to !i386, I will. If an architecture indep package must go in, it will also update i386 (but not the i386 CD images, which are already done). We will lose some consistency, but we're already going to be 90% more consistent than the last beta this way. - When the music stops, those ports that have d-i candidates in testing will be released as beta2. Is that right? Right on all counts. Note that sarge/main/debian-installer/binary-i386 currently has empty Packages files. They were fine yesterday but one of the girls ate them. I think that will be fixed tomorrow after ftpmaster finished getting their act together. -- see shy jo signature.asc Description: Digital signature
