As much as I can rely on the OP status here, I wish this discussion stay constructive as I positively appreciate advises and suggestions of all who posted in this thread so far.

I never have stated that a localized installer don't work. I just pointed out that IMHO a localized documentation is far more important than a localized program. Stop putting words in my mouth and twisting them around.

You are entitled to believe what you want. That doesn't mean that it is true. I simply missed the "Translations" link on the Slackbook website. That you think you are able to come to such conclusions by a few posts here without knowing me at all actually says more about you than about me.

As I already stated, I stand corrected, there are translations of the Slackbook. You state that you have used it, fine. But you still used the English installer, didn't you? And as stated before, the discussion was about people not being able to use the installer. You, as you have stated yourself, were being able to use it, with the help of translated documentation, which a) not only means that you are not the type of user we are speaking of, and b) proves my point.

So, let us get back ontopic, as Didier Spaier rightfully reminds us. Now that I know that documentation is available in other languages, I have no other point speaking against localized tools than that it will be more difficult to help people that are using them. This is a rather annoying than a show stopper, I would think.

1 members found this post helpful.

Yes this is annoying. As I wouldn't hold my breath till we have a localized LQ (I won't even dare to request that), I just hope that someone takes the initiative of running a forum dedicated to help Slackers in their language. At least there is one in my native language

And you need a business model, because Slackware is a commercial distribution. And this is what happens:

1. You create a German-translated version of Slackware and sell it successfully in Germany, Austria and Switzerland.
2. Your German-speaking customers request changes to the distribution.
3. You modify your localized version and 17 years later you end up with OpenSuSE.

And sorry to disillusion you: But selling Slackware to computer illiterate home users isn't gonna work in 2012.

Is selling Slackware to any kind of Slackware users working either?

Patrick J. Volkerding is the decider for Slackware's business model, not Didier Spaier.

But a desirable side effect of localizing Slackware tools, thus increasing Slackware's user base, *could* be to increase Slackware Store's sales which would help to support Slackware.

Hi,

I had an idea today. As you know there's a localization-SlackBuild.script which AlienBob wrote for Mozilla-Firefox: http://slackware.com/~alien/slackbui...-firefox-l10n/

I think we should consider to provide localization via SlackBuilds. This will not work for the installer, but maybe in many places of a Slackware-installation.
The advantage is, that the Slackwareteam can do their work as usual.

Anyone who has an idea how to localize packages for his language (or as a generic Slackbuild for all languages) can contribute and upload his/her l10n-SlackBuild.script for package foo to slackbuilds.org.

This could be an interesting approach for many of us who want to improve their scripting-skills.

Markus

This special treatment is only needed for Firefox, because it is mainly developed on and for Windows, where multilingual software is unusual. Most packages use gettext or something similar and can change their display language on the fly based on environment variables (LANG, LC_MESSAGES).

Yes, I know that, but I thought of for example the settings in /etc/X11/xorg.conf.d/
Why not install 90-keyboard-layout.conf as a Slackbuild for various languages? Same for the LANG variable. It should be easy to create a slackpkg which makes all these settings for example for german in one step.

I think the advantage of this approach is, that it doesn't change Slackware in general.

Markus

The X keyboard layout should be configured with Slackware's xorgsetup. But I don't know, if this tool still works after the introduction of the hald/udev mess. At least in 14.0 you don't have to create obscure XML files anymore.

As far as I know xorgsetup writes an xorg.conf which actually isn't necessary.

Markus

It would mainly be to make a list of all the applications misbehaving in UTF-8 and find workarounds/patches for them. But as far as I see from my own system, passing to UTF-8 is not system-wise painful at all (my main issue was to convert my own text-based stuff). Plus, many applications does not really need to know anything about UTF-8. For example, the coreutils don't support it (see below), but this does not prevent them to do their daily job.

The man Slackware ships is UTF-8 compatible (groff is). What it can't do is to determine if a page is or is not in UTF-8, so sometimes you get an UTF-8 page converted in UTF-8 as if it was in a 8bits charset. Declaring Slackware is from now on an UTF-8 based distro could fix this (the pages not in UTF-8 -- but many are in -- would be converted as a fix in the SlackBuilds).

Now, to come back to the object of the topic, I would prefer to see the installer staying in ASCII:

1) it's more solid. I've already had some issues with an UTF-8 locale in busybox. Of course, it's a well maintained project, where you can get fixed the bugs you report, but an installer has IMHO to be 100% reliable before being able to support such things as localization ;
2) localization of the installer means to embbed a lot of fonts in the installer, which is already > 50MB in RAM (without the kernel) ;
3) as already said by someone else above, some fonts won't be available unless you run X, which means to add a working X and to loose (or make much trickier) the ability for Slackware to be installed on an headless machine ;
4) I can't localize LILO or EXTLINUX, but I really don't care -- I don't even look for fixing this. Why ? because I see it 8s max per day. This is almost the same with setup I see once or twice a year. As TobiSGD said, a good documentation is far more useful than a localized interface (BTW, explaining the sense of each item is already a kind of translation) for the Slackbeginners (which are unlikely to be computer-illiterate, these people finding difficult everything you can't click on -- not despising here, it's just the basic "computer culture" the average people are risen in). Don't get me wrong, I enjoy a lot having my system in French, the point is that we don't live with the installer, it's just a little step (which moreover does not change much from a release to another, so at the end you don't even read the item) to get the things where localization really matters.

Just my 2¢.

Thanks NonNonBa for your input.

(1) I like your idea of making "a list of all the applications misbehaving in UTF-8 and find workarounds/patches for them".
(2) I like your other idea of finding, then converting, the man pages not yet encoded in UTF-8.
Both suggestions should feed our TODO list.

About the installer, I am not very pleased by your suggestion not to localize it and am not ready to give up on that but I take your objections seriously, so let's deepen the issues you raise.
(1) Could you please elaborate a bit about the issues you had with an UTF-8 locale in Busybox ? I am ready to post some inquiry about the current and future status of UTF-8 support in the Busybox mailing list, but I wish I could feed it with examples of "real life" issues or shortcomings.
(2) About embedding a lot of fonts in the installer I assume that we don't need to include all the console fonts shipped in the 'kbd' package, so we could restrict the fonts embedded in the installer to the minimum needed to have it working in UTF-8.
By the way, determining which fonts we would really need then is another item to add to the TODO list.
(3) I think that we should try hard to restrict the fonts used to console fonts as I of course agree that we should avoid to embed an X server in the installer. In addition I wouldn't dare to request that to PV as I can easily guess what would be his response...
(4) localizing lilo is not really necessary IMO. But localizing liloconfig is, and seems feasible.

Not sure I understand your point about coreutils, but at least coreutils is localized and the .po files use UTF-8 encoding. You can check that typing 'msgunfmt -o coreutils.po /usr/share/locale/zh_CN/LC_MESSAGES/coreutils.mo" then opening the file coreutils.po in an utf-8 able text editor. I did that with geany and pour moi, c'est bien du Chinois.
By the way, doing a 'cat coreutils.po' in console mode could be a way of checking which glyphs we miss for localization in Chinese, see (2)

PS And by the way we do not need to be comprehensive from day one: if we miss a few glyphs used in a specific locale, either it is not a show stopper and translators can do without it or availability of this locale in the installer and other Slackware tools will have to wait till we find an appropriate font, which could mean wait till next Slackware release as in Slackware parlance 'stable' means 'stable'.

An idea calling another one (does this expression make sense in English?) I specify that IMO the release of a new locale should occur only:
(1) On occasion of a Slackware release.
(2) When it's ready, in the pure Slackware tradition.

In particular, (2) means that we will have to specify which minimum set of tools should be fully translated before a new locale can be released.

So, sorry to deceive the impatient among us, we won't release anything this year, and more specifically before Slackware next be released.

Well, I found back my bug report on the busybox ML.

UTF-8 has nothing to do with the fonts. You need a font to support a *language* (e.g. nevermind if you use ru_RU.koi8r or ru_RU.utf8, what you need is the cyrillic characters to support Russian). So, if you want a localized output for every Slackers, you probably need a lot of fonts.

The coreutils use gettext to localize their messages, which is probably UTF-8 capable. But most of the coreutils themselves are not, so they consider evereything you pass to them as 8bits chars encoded-data. Plus, don't forget UTF-8 is also made with 8bit char sequences, which means whether or not it will be well handled depends of the final application which will display them. If you "cat" an UTF-8 text in an UTF-8 xterm, it will works, if you "cat" it in an byte-oriented xtem, it won't. cat has nothing to do with that, it does not need to know if each 8bit sequence is or is not a char to do its job (but cut and wc need, that's why I can show they don't support it).

In fact, you could go faster if you would stick with latin/cyrillic/greek... languages for the first release. This would allow you to not care about the UTF-8 issues while covering a large base of potential users, enough to see if the project feeds a real lack. Then, if it succeeds, it would be time to care of more sophisticated issues.

Plus, you don't even need your project to be integrated in upstream. Make a standalone installer system is not difficult. So, you can just provide an image of your localized installer to be loaded on an USB stick (glance at isolinux/isohybrid). The users boot with it, and then insert the complete DVD in their drive, to get a localized installation exactly as if it was from the original DVD.

Thanks again for your remarks, Seb.

Thanks. As neither ash nor su are being used in Slackware's installer, I assume we shouldn't encounter this particular issue though.

Right. I just wanted to say that the less encoding we ship, the more space we save. And we could request the translators themselves or some other people to propose fonts including the needed glyphs.

Yes. And in fact we could work in parallel on the two projects: I18N/L10N and UTF-8 usage.

Yes. Though I wish the project be eventually integrated in upstream, making a standalone localized installer would certainly be useful at least transiently:
(1) As a proof of concept, IOW to demonstrate its feasibility.
(2) To check that the project feeds a real lack.

Indeed... Pat chose to embbed bash instead of ash in the 14's installer.

BTW, about su, it's not a busybox-related issue. It comes from the default configuration, which defines SU_NAME, so (in login mode) the argv[0] of the system's su can't anymore tells to busybox the name of the applet to call.

The "problem" is that the applications beyond X generally handle UTF-8 very well. So very few people will encounter problems during their every days usage. Look at the BSDs, AFAIK, their console does not support UTF-8, but still it's considered as a low-priority issue.

The manuals are the major issue, right, but using things like rxvt-unicode helps a lot (it can fix the forbidden 8bits single chars sent to it set in UTF-8).

But, well, if people are still interested in getting a full-unicode Slackware, I can nevertheless begin a dedicated thread.

Yes, I thought the things in this way. Slackware is a conservative distro, that's a fact (which is sometimes good, and sometimes bad). You would IMHO have more weight to change things with a functionnal and popular project. Good luck.