Debian installer build: failed or old builds
Debian installer build overview --- Failed or old builds: * OLD BUILD:sparc Mar 14 00:10 buildd@sompek build_cdrom http://d-i.debian.org/daily-images/sparc/daily/build_cdrom.log * OLD BUILD:sparc Mar 14 00:14 buildd@sompek build_netboot http://d-i.debian.org/daily-images/sparc/daily/build_netboot.log * OLD BUILD:sparc Mar 14 00:18 buildd@sompek build_miniiso http://d-i.debian.org/daily-images/sparc/daily/build_miniiso.log Totals: 117 builds (0 failed, 3 old) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1s9qx9-000636...@ravel.debian.org
Processed: These belong to debian-installer
Processing commands for cont...@bugs.debian.org: > reassign 664420 debian-installer Bug #664420 [debian installer] Adding New Script Variants on Debian Installer Warning: Unknown package 'debian' Warning: Unknown package 'installer' Bug reassigned from package 'debian installer' to 'debian-installer'. > reassign 664486 debian-installer Bug #664486 [debian installer] Adding New Script Variants on Debian Installer Warning: Unknown package 'debian' Warning: Unknown package 'installer' Bug reassigned from package 'debian installer' to 'debian-installer'. > thanks Stopping processing here. Please contact me if you need assistance. -- 664420: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664420 664486: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664486 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133211173419011.transcr...@bugs.debian.org
Re: Adding New Script Variants on Debian Installer
On Sun, Mar 18, 2012 at 4:24 PM, Wouter Verhelst wrote: > > Yes, it is. What you're describing is a bug waiting to happen. > > For comparison: there is no translator who translates to the 'nl_BE' > locale; all dutch translators translate to 'nl'. Yet there is no user > who uses an 'nl' locale; all users use 'nl_NL', 'nl_BE', 'nl_AR', or > whatnot. The locales system understands that Dutch is Dutch, no matter > where it's spoken, and will take the 'nl' translation when 'nl_BE' is > asked. > > In the case of Dutch, that's perfectly reasonable, because there's only > one authority on the Dutch language (the Dutch Language Union). This > isn't just limited to Dutch, however; in simple programs, it could be > that the only needed strings aren't of the variant where there's a > difference between en_US and en_GB, in which case you'll end up with > just an 'en' translation. > > This assumption that "'xx_YY' is just a specialized form of 'xx'" means > that it's okay to move files around if you find that there are > translations for this one specialized variant of ug but not for that > other, and your users are asking for a translation. When that happens, > with your scheme, suddenly you get a translation that jumps from one > script to the other all the time; this is even worse than having a > partially-translated program. > > Also, the fact that one translation has such a bug shouldn't mean that > the other should, too. > > -- > The volume of a pizza of thickness a and radius z can be described by > the following formula: > > pi zz a > Thank you so much for your explanation. It is crystal clear to me now. ug_CN is a well established locale for Uyghur (Uighur) language in China, which uses modified Arabic-Persian. Then, what is the best way to name the Latin based Uyghur locale used globally? Should a locale be always tied up to a specific country? Which one of the following names are best and acceptable? Could you please explain the pros and cons of each one? ug@latin ug_CN@latin ug_US@latin Thank you very much again.
install manual
To whom it may concern, I've put f...@funlabs.org in the CC line because it is in the tail of the webpage. http://d-i.alioth.debian.org/manual/ contains several links to the domain ettin.org in the section "XML-based translations". Problem is that ettin.org returns a 404 on pub/debian/dimstats/* and that is too bad. Possibly the page is outdated and I have not come round to checking the svn checkout of the install manual. I'm interested in helping out with the Dutch translation, as I'm a Dutch native speaker and I saw that 102 pages still need translation if that number is accurate. greatings, Bernard Zijlstra -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1332077421.1345.60.ca...@debbook.quadzero.nl
Re: Adding New Script Variants on Debian Installer
On Sun, Mar 18, 2012 at 07:13:43AM -0500, Eagle Burkut wrote: > Before we came to that naming convention, we did a quite bit of research. > There > are couple of obstacles to adopt the other idea. First of all, the FontConfig > library does not support with language/script variant with @ such as ug_CN, > and > ug_CN@latin. There is no way to develop a orthography rule file for > ug_CN@latin > and have it included in FontConfig. Secondly, the online translation platform > Launchpad does not support another language/script variant of the same > language > in same country. These are originally design issues and in the near > foreseeable > future, there is no clear indication that there will be a fix. And lastly, > while doing a research on this issue, the Kurdish language in Turkey, Iraq and > Iran draw our attention. There are just language and country code, no @ > variants. Our case is exactly same as of Kurdish, nothing more or nothing > less. > The @ variant has to be used for the same language in same country, such as > uz_UZ@latin and uz_UZ@cyrillic. For same the language in different countries, > there is no need to add the @ variant, such as in the case of Kurdish. And in > our case, for the same language, different writing systems are used in > different countries, not in the same one country, thus we think the @ variant > is not necessary. Yes, it is. What you're describing is a bug waiting to happen. For comparison: there is no translator who translates to the 'nl_BE' locale; all dutch translators translate to 'nl'. Yet there is no user who uses an 'nl' locale; all users use 'nl_NL', 'nl_BE', 'nl_AR', or whatnot. The locales system understands that Dutch is Dutch, no matter where it's spoken, and will take the 'nl' translation when 'nl_BE' is asked. In the case of Dutch, that's perfectly reasonable, because there's only one authority on the Dutch language (the Dutch Language Union). This isn't just limited to Dutch, however; in simple programs, it could be that the only needed strings aren't of the variant where there's a difference between en_US and en_GB, in which case you'll end up with just an 'en' translation. This assumption that "'xx_YY' is just a specialized form of 'xx'" means that it's okay to move files around if you find that there are translations for this one specialized variant of ug but not for that other, and your users are asking for a translation. When that happens, with your scheme, suddenly you get a translation that jumps from one script to the other all the time; this is even worse than having a partially-translated program. Also, the fact that one translation has such a bug shouldn't mean that the other should, too. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120318212408.gp13...@grep.be
Re: cdebconf 0.159
Regis Boudin wrote: > That's a bit odd, the initial setup and conversion is done in the > config > script, and I would have expected debconf to have already run it > before. > Unless I got it wrong with my almost empty postinst. FWIW, I saw the same thing; debconf was using dialog and cdebconf defaults to text. -- see shy jo signature.asc Description: Digital signature
Re: cdebconf 0.159
Regis Boudin wrote: > >Perhaps it's time to get some wide testing? This could be done by > >temporarily making debconf default DEBCONF_USE_CDEBCONF=1 > > Sounds like an idea. the various scripts will probably need an > additional > check for cdbconf's existence, though, since it caused me trouble I was assuming we'd make debconf depend on it, although this would technically violate its Priority value. For temporary testing it seems ok. -- see shy jo signature.asc Description: Digital signature
Re: cdebconf 0.159
Quoting Regis Boudin (re...@boudin.name): > An obvious one for you should be the complete absence of i18n for > cdebconf itself. It would be nice if someone could review what I did > for > the frontend selection to make sure it's ok before marking the > templates > as translatable. Aren't texts identical to debconf ones? I was thinking so, so I never paid attention to this very strongly. At least they should be similar, so we should reuse debconf translations so that translators do not start from scratch. signature.asc Description: Digital signature
Re: Adding New Script Variants on Debian Installer
Quoting Eagle Burkut (eagle.bur...@gmail.com): > > But, really, ug_US should not happen and I doubt upstream glibc > > maintainers accept it. > > > As long as they use different country code, it will work. > > ug_CN > ug_KZ@cyrillic > ug_US@latin (or ug_XX@latin, XX other than CN or KZ) > > For the Latin based Uyghur, United States is the country where it is used > heavily. I'm not convinced at all by these arguments. MOreover, I think the Kurdish example is really plain wrong. And more generally, basing something related to *languages* on *country* codes (something that is likely to change over time) is just a deviation from the spirit of what a local is. In a locale, the country part represent things that vary from one country to another (such as the currency name, symbol, postal codes, the way one writes postal addresses, etc.). So, using the country code as something to differentiate things that are *not* related to the countries but more to variations in the language, is what I would call in French a "détournement" (sorry, missing the right English word, here). So, would I be glibc upstream, I would not accept this locale. Not to mention the "US" part which is, I think, strongly biased or could even be viewed as politically oriented. I would rather recommend the approache of Esperanto : use a locale without any country modifier (the Esperanto locale is "eo" alone), thus ug@latin. -- signature.asc Description: Digital signature
Re: cdebconf 0.159
On Fri, 16 Mar 2012 13:40:22 -0400, Joey Hess wrote: Regis Boudin wrote: Hi everyone ! That's it, after a month of testing on my main machine, I uploaded cdebconf 0.159. Although some features are still missing, it should actually be usable. Well, I've been using it on my main machine for a month with 2 daily updates, and a few "dpkg-reconfigure -a", and all blocking issues I've seen since August have been identified and fixed. Also, interesting milestone I believe, with a script modified only to add cdebconf to the required packages if DEBCONF_USE_CDEBCONF is set, I could debootstrap a chroot, and compile a KDE application with cowbuilder. Perhaps it's time to get some wide testing? This could be done by temporarily making debconf default DEBCONF_USE_CDEBCONF=1 Sounds like an idea. the various scripts will probably need an additional check for cdbconf's existence, though, since it caused me trouble Independant of that, it would be good to get cdebconf to the point it does not depend on debconf. That would certainly be very nice. The main reason to keep the dependency so far has been because when some scripts were causing trouble I could switch back easily to finish installing packages. Also because I'm not certain how to handle the transition. Anyway, thanks for the feedback. Regis -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0f778ec85ddf9b79fbf16f0eccb90...@imalip.net
Re: cdebconf 0.159
On Sat, 17 Mar 2012 08:16:56 +0100, Christian PERRIER wrote: Quoting Regis Boudin (re...@boudin.name): Hi everyone ! That's it, after a month of testing on my main machine, I uploaded cdebconf 0.159. Time for me to switch..:-) Oh, so I'll start breaking people's machine, now ! First glitch I had : I did setup DEBCONF_USE_CDEBCONF=1, then I ran "dpkg-reconfigure samba" and.I ended up with the "text" interface and not the "newt" one. Running "dpkg-reconfigure cdebconf" (which indeed defaulted to "newt" for the interface) fixed the problem. That's a bit odd, the initial setup and conversion is done in the config script, and I would have expected debconf to have already run it before. Unless I got it wrong with my almost empty postinst. Other glitches will come later on (though I don't do much interactive use of debconf as my laptop is mostly updated with apt-cron). An obvious one for you should be the complete absence of i18n for cdebconf itself. It would be nice if someone could review what I did for the frontend selection to make sure it's ok before marking the templates as translatable. Regis -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/d338707f7576bc979d7edd228cfbf...@imalip.net
Re: Proposal to get Wheezy Alpha1 done
On Sat, Mar 17, 2012 at 03:42:03PM -0300, Otavio Salvador wrote: > On Sat, Mar 17, 2012 at 15:37, Adam D. Barratt > wrote: > >> partman-nbd > > > > Not done. The files client.c, oef and opdr have all disappeared and a > > chunk of code has changed in resolv.c, without any mention in the > > changelog. > > Wouter can you comment on that? Whoops. Apparently my 0.8 upload was done without checking "git status" first. Sorry 'bout that. The first three should not have been there in the first place; they are completely and utterly unrelated to partman-nbd. The changes to resolv.c were a work in progress; I'm not sure whether they were actually tested. I'll do so ASAP, and upload a fixed 0.10 when that's done. Meanwhile, 0.9 is actually in better state than 0.8 was (as in, less features but what's there has actually been tested), so go ahead and let it pass. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120318145403.gb14...@grep.be
Re: Adding New Script Variants on Debian Installer
On Sun, Mar 18, 2012 at 6:03 AM, Christian PERRIER wrote: > > I'm afraid, this is an incorrect use of locales. > > Country modifiers shouldn't be used for language variants. So a ug_US > locale means nothing (Uyghur in United States of America? Why not > ug_UK or ug_PT or whatever?). > > The correct locale for "Uyghur written in latin script" should be > "ug_CN@latin" (and eventually ug_XX@latin, in case Uyghur is widely > used in another country than "China", such as Kazakhstan, for > instance. > > And, in case Uyghur is also written in Cyrillic, as you seem to imply, > then the right locale would be ug_XX@cyrillic, where XX is the country > where the cyrillic variant is the most widely used .I guess KZ, > then > > I would strongly advise against using ug_KZ to denote "Uyghur written > in cyrillic ". It should be kept for "Uyghur written in Arabic script, > in Kazakhstan" (and if that means nothing as Uyghur is never written > in arabic script in KZ, then don't create the locale but create > ug_KZ@cyrillic). > > But, really, ug_US should not happen and I doubt upstream glibc > maintainers accept it. As long as they use different country code, it will work. ug_CN ug_KZ@cyrillic ug_US@latin (or ug_XX@latin, XX other than CN or KZ) For the Latin based Uyghur, United States is the country where it is used heavily.
Re: Adding New Script Variants on Debian Installer
On Sun, Mar 18, 2012 at 6:03 AM, Christian PERRIER wrote: > Quoting Eagle Burkut (eagle.bur...@gmail.com): > > > While we have finished translating more than 95% translation string in > > Ubuntu (that is 350,000 sentences!), due to lots of bugs and inabilities > in > > various libraries/packages/fonts, we got a localized Ubuntu with lots of > > bugs/errors. In summary, the original Ubuntu has problems, bugs in every > > aspect of > > Hmmm, all what I like in Ubuntu l10n infrastructure: even upstream > software is translated through Rosetta/Launchpad and nobody has any > idea about the translations ending up in upstream software. In short: > they don't benefit anything but Ubuntu users. VERY sad. > > Why wouldn't Fedora users be able to use Libreoffice, Firefox, Gimp, > etc, in Uyghur? > LibreOffice and Firefox are translated in upstream, it is not part of the Ubuntu translation process. > Anyway...let's just hope that Ubuntu/Canonical jave a magic system for > making this happening...but I would be surprised. > What makes Ubuntu different from other Linux distributions is that, in my view, Ubuntu/Canonical is working harder to actively support the development, localization, and translation workflow. I have not seen the same level of support and effort from other distributions. > > > > (1) Right-to-Left support > > (2) Bi-Directional support > > (3) Font selection > > (4) Proper fonts > > > > Thus, even with hundreds of translator spending couple of years of hard > > work, we still ended up not so good localized Ubuntu. > > > > If we utilize Latin based Uyghur, all of the above problems will > disappear > > immediately. That is why we are thinking about adding Latin based Uyghur > to > > Ubuntu, including the Debian Installer. > > Then why not work on these problems rather than circumventing with > hacks? > We tried very hard on this problems. There are many parties involved in these problems and it is not easy to identify the source, and worst of all, almost all sides deny that those bugs really come from their work. First of all, there is no proper font to support Uyghur in open source community. Unfortunately, due to the file size limit of Ubuntu distribution, we can not have our own fonts included in the distribution ISO/CD. And the mixture of the Ubuntu selected fonts, FontConfig, Unity, Gnome, almost all parties said that the bugs are not related to themselves, they are from other sources... With limited manpower and technical expertise, we can not check all of the source codes line by line to identify the sources of the bugs. It is really frustrating. > > As Uyghur is written in modified Arabic-Persian in China, in Cyrillic in > > Kazakhstan and central Asia, and in Latin elsewhere globally, we > previously > > had ug_CN locale in Arabic, and we have just developed ug_US locale in > > Latin and submitted it to upstream glibc library, and more, we are > planning > > to develop ug_KZ locale in Cyrillic in near future. > > I'm afraid, this is an incorrect use of locales. > > Country modifiers shouldn't be used for language variants. So a ug_US > locale means nothing (Uyghur in United States of America? Why not > ug_UK or ug_PT or whatever?). > Latin based Uyghur is not used inside China and Kazakhstan at all. It is used mainly outside of China, especially in North America and other western countries. Among them, United States is the country where the Latin based Uyghur is used heavily among its Uyghur residents. The correct locale for "Uyghur written in latin script" should be > "ug_CN@latin" (and eventually ug_XX@latin, in case Uyghur is widely > used in another country than "China", such as Kazakhstan, for > instance. > > And, in case Uyghur is also written in Cyrillic, as you seem to imply, > then the right locale would be ug_XX@cyrillic, where XX is the country > where the cyrillic variant is the most widely used .I guess KZ, > then > > I would strongly advise against using ug_KZ to denote "Uyghur written > in cyrillic ". It should be kept for "Uyghur written in Arabic script, > in Kazakhstan" (and if that means nothing as Uyghur is never written > in arabic script in KZ, then don't create the locale but create > ug_KZ@cyrillic). > > But, really, ug_US should not happen and I doubt upstream glibc > maintainers accept it. Before we came to that naming convention, we did a quite bit of research. There are couple of obstacles to adopt the other idea. First of all, the FontConfig library does not support with language/script variant with @ such as ug_CN, and ug_CN@latin. There is no way to develop a orthography rule file for ug_CN@latin and have it included in FontConfig. Secondly, the online translation platform Launchpad does not support another language/script variant of the same language in same country. These are originally design issues and in the near foreseeable future, there is no clear indication that there will be a fix. And lastly, while doing a research on this issue, t
Re: Adding New Script Variants on Debian Installer
Quoting Eagle Burkut (eagle.bur...@gmail.com): > While we have finished translating more than 95% translation string in > Ubuntu (that is 350,000 sentences!), due to lots of bugs and inabilities in > various libraries/packages/fonts, we got a localized Ubuntu with lots of > bugs/errors. In summary, the original Ubuntu has problems, bugs in every > aspect of Hmmm, all what I like in Ubuntu l10n infrastructure: even upstream software is translated through Rosetta/Launchpad and nobody has any idea about the translations ending up in upstream software. In short: they don't benefit anything but Ubuntu users. VERY sad. Why wouldn't Fedora users be able to use Libreoffice, Firefox, Gimp, etc, in Uyghur? Anyway...let's just hope that Ubuntu/Canonical jave a magic system for making this happening...but I would be surprised. > > (1) Right-to-Left support > (2) Bi-Directional support > (3) Font selection > (4) Proper fonts > > Thus, even with hundreds of translator spending couple of years of hard > work, we still ended up not so good localized Ubuntu. > > If we utilize Latin based Uyghur, all of the above problems will disappear > immediately. That is why we are thinking about adding Latin based Uyghur to > Ubuntu, including the Debian Installer. Then why not work on these problems rather than circumventing with hacks? > As Uyghur is written in modified Arabic-Persian in China, in Cyrillic in > Kazakhstan and central Asia, and in Latin elsewhere globally, we previously > had ug_CN locale in Arabic, and we have just developed ug_US locale in > Latin and submitted it to upstream glibc library, and more, we are planning > to develop ug_KZ locale in Cyrillic in near future. I'm afraid, this is an incorrect use of locales. Country modifiers shouldn't be used for language variants. So a ug_US locale means nothing (Uyghur in United States of America? Why not ug_UK or ug_PT or whatever?). The correct locale for "Uyghur written in latin script" should be "ug_CN@latin" (and eventually ug_XX@latin, in case Uyghur is widely used in another country than "China", such as Kazakhstan, for instance. And, in case Uyghur is also written in Cyrillic, as you seem to imply, then the right locale would be ug_XX@cyrillic, where XX is the country where the cyrillic variant is the most widely used .I guess KZ, then I would strongly advise against using ug_KZ to denote "Uyghur written in cyrillic ". It should be kept for "Uyghur written in Arabic script, in Kazakhstan" (and if that means nothing as Uyghur is never written in arabic script in KZ, then don't create the locale but create ug_KZ@cyrillic). But, really, ug_US should not happen and I doubt upstream glibc maintainers accept it. -- signature.asc Description: Digital signature
Re: Proposal to get Wheezy Alpha1 done
Thijs Kinkhorst (18/03/2012): > Perhaps you want to consider gnupg 1.4.12 too? It has been in unstable for > 17 days (change in 1.4.12-4 was only relevant for debian-ports archs) and > no issues have been reported. Looks good, done so. Mraw, KiBi. signature.asc Description: Digital signature
Re: Proposal to get Wheezy Alpha1 done
On Sat, March 17, 2012 18:37, Otavio Salvador wrote: > Hi Release Team, > > On Sun, Mar 11, 2012 at 14:55, Otavio Salvador > wrote: >> * on 03/17 try to get the packages migrated to testing > > Please age the following packages: Perhaps you want to consider gnupg 1.4.12 too? It has been in unstable for 17 days (change in 1.4.12-4 was only relevant for debian-ports archs) and no issues have been reported. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/f736d5f14cd6e86840a87efea117aff0.squir...@wm.kinkhorst.nl
Re: Adding New Script Variants on Debian Installer
Package: Debian Installer On Sun, Mar 18, 2012 at 1:38 AM, Christian PERRIER wrote: > Quoting Eagle Burkut (eagle.bur...@gmail.com): > > Dear Debian Developers/Maintainers, > > > > How can we have new language/script on debian installer? Is there any > > requirement? If there is, what is the requirement? > > > > Ubuntu uses Debian Installer and it has Arabic based Uyghur. We need > Latin > > based Uyghur too. > > > We need to go though the whole New Language Process as we did for "ug" > with Gheyret Kenji > > Please notice however, that a new translation adds an extra size to > the installer so we need some good rock solid rationale for adding a > variant of an existing language. > While we have finished translating more than 95% translation string in Ubuntu (that is 350,000 sentences!), due to lots of bugs and inabilities in various libraries/packages/fonts, we got a localized Ubuntu with lots of bugs/errors. In summary, the original Ubuntu has problems, bugs in every aspect of (1) Right-to-Left support (2) Bi-Directional support (3) Font selection (4) Proper fonts Thus, even with hundreds of translator spending couple of years of hard work, we still ended up not so good localized Ubuntu. If we utilize Latin based Uyghur, all of the above problems will disappear immediately. That is why we are thinking about adding Latin based Uyghur to Ubuntu, including the Debian Installer. Also, variants have not been proven as working properly as of now : we > for instance have a "sr@latin" variant for Serbian that is not > activated yet because supporting it requires changes to localechooser > that nobody did until now. > > (the main problem comes from the fact that localechooser assumes that > the chosen language code and the chosen country can be concatenated : > fr for language then FR as country, give "fr_FR".while this > doesn't work for "sr@latin" combined with a country code such as "RS" > as the locale should be "sr_RS@latin", not sr@latin_RS) > As Uyghur is written in modified Arabic-Persian in China, in Cyrillic in Kazakhstan and central Asia, and in Latin elsewhere globally, we previously had ug_CN locale in Arabic, and we have just developed ug_US locale in Latin and submitted it to upstream glibc library, and more, we are planning to develop ug_KZ locale in Cyrillic in near future.
Re: Adding New Script Variants on Debian Installer
On Sun, Mar 18, 2012 at 1:38 AM, Christian PERRIER wrote: > Quoting Eagle Burkut (eagle.bur...@gmail.com): > > Dear Debian Developers/Maintainers, > > > > How can we have new language/script on debian installer? Is there any > > requirement? If there is, what is the requirement? > > > > Ubuntu uses Debian Installer and it has Arabic based Uyghur. We need > Latin > > based Uyghur too. > > > We need to go though the whole New Language Process as we did for "ug" > with Gheyret Kenji > > Please notice however, that a new translation adds an extra size to > the installer so we need some good rock solid rationale for adding a > variant of an existing language. > While we have finished translating more than 95% translation string in Ubuntu (that is 350,000 sentences!), due to lots of bugs and inabilities in various libraries/packages/fonts, we got a localized Ubuntu with lots of bugs/errors. In summary, the original Ubuntu has problems, bugs in every aspect of (1) Right-to-Left support (2) Bi-Directional support (3) Font selection (4) Proper fonts Thus, even with hundreds of translator spending couple of years of hard work, we still ended up not so good localized Ubuntu. If we utilize Latin based Uyghur, all of the above problems will disappear immediately. That is why we are thinking about adding Latin based Uyghur to Ubuntu, including the Debian Installer. > Also, variants have not been proven as working properly as of now : we > for instance have a "sr@latin" variant for Serbian that is not > activated yet because supporting it requires changes to localechooser > that nobody did until now. > > (the main problem comes from the fact that localechooser assumes that > the chosen language code and the chosen country can be concatenated : > fr for language then FR as country, give "fr_FR".while this > doesn't work for "sr@latin" combined with a country code such as "RS" > as the locale should be "sr_RS@latin", not sr@latin_RS) > As Uyghur is written in modified Arabic-Persian in China, in Cyrillic in Kazakhstan and central Asia, and in Latin elsewhere globally, we previously had ug_CN locale in Arabic, and we have just developed ug_US locale in Latin and submitted it to upstream glibc library, and more, we are planning to develop ug_KZ locale in Cyrillic in near future.
