The idea as an idea sounds pretty interesting. Localized installer would help with the users who can't understand any english. But on the other note, I doubt most of the users seriously read any text while installing the software/OS. Yeah, I know they should, but they don't.

I agree with TobiSGD it would complicate diagnostics. I am also using UTF-8 variant of en_US locale. GNU userspace is not completely localized in my language, so I get mixed cyrillic and latin letters (with rs locale) anyway. And translations are sometimes dubious. I don't wish to undervalue the work and time of the translators, but it's a fact. So sometimes, reading localized error messages is somewhat like decyphering. IE: they often use the words they think should be used, but that are not common in the spoken language. So it ends up with translating every term just to be language correct. Yep, it's a battle against anglicisation of the language. It makes sense on some level. But it also makes the translation hard to understand until you get to know their wording.

They will not make such changes to releases anyway. And when they make changes in -current, it's less important if it can be done atomically in all locales.

Would you please elaborate, I do not quite understand the atomic part. If there is a change in the installer in -current, I really doubt that the Slackware team will take the time to do the translation. That means that the change in the installer will either leave all other translations with the English text or it will be not displayed at all. Both cases have to be solved before the next release, otherwise it will directly reflect on Slackware's good reputation. But what is when the former translator of a language with a small userbase may be has lost the interest in doing further translations? Who will step up to do it? Or will that language simply be ditched? Or will the release be delayed?

There is a reason why Slackware is developed by a small team without much direct influence from the outside and we all know that reason: To maintain Slackware's stability and integrity. Giving the translations of such integral and important parts of Slackware to the community is IMHO directly opposed to that type of handling things.

Again, I am not against making Slackware fully UTF-8 compatible. But please leave such integral parts like the installer or the tools like pkgtool alone. In the end that may look nice, but will make things, from development over documentation to troubleshooting/helping to troubleshoot, much more complicated. IMHO, the downsides outweigh the benefits by far.

No. The Slackware team won't.

Quite right.

Yes this is the barrier of committing translations. And ...

... if the translations cannot be committed until the RC stage, it can be dropped (ditched).

At the same time, I'm pretty confident that the Slackware team will make changes other than bugfixes to the installer at the last moment.

I personally don't like translation of the installer either, as I expressed in this thread before. But what I don't want is not necessarily useless. English is not that popular in some places (my parents' home for example), especially en_US which is its deteriorated variant.

Generally speaking of error/warning messages, localization is more useful. e.g.

• A system showing localized error messages in German makes my Kollegin happy and more wishing to go out with me.
• Warnings from gcc in my language shows distinctly different characters than English letters. It's much easier for my eyes to spot potential errors in my source code.

In the contrary, it is more difficult to find solutions on the net with localized error-messages, especially if your language is not that widely spoken and more especially if you are not computer-literate, since in that case you will have more problems to translate the unknown to you technical terms to English. Like it or not, the most spoken language in that field simply is English (en_US).

And again, run your system in any language you want, that is not my concern, although alone this makes it more difficult, at least to me, to help someone with error messages in a language I don't understand. But that is not my point.
I still think that the key tools should not be translated, but remain in plain English. Look in the Slackbook. Try to follow the description of the installing process or the usage of pkgtool with setting the language for them to Africaans. You see the problem here? Translating Slackware specific tools means that every part in the documentation that is describing them has also to be translated, which is an enourmous effort. But without that translation the downsides of internationalized tools outweigh the benefits by far, especially for the computer illiterate people.

In short: Make Slackware UTF-8 compatible, run it in any language you want, but don't touch the Slackware specific tools until you have fully translated that tools documentation. Otherwise you will get the babylonian mess that should be avoided.

On the contrary, I often only need to know whether there's anything wrong or not. When I know something is wrong I often fix it without looking at the error message in details -- simply because the compiler is often not intelligent enough to figure out the real cause of the problem.

Because of this, the more different my language is from English the easier it is for me to catch warnings in the fast scrolling "make" output.

True, since you are computer literate. For the computer illiterate (most likely not a programmer) with a not widely spoken language it is far more difficult to find relevant information on non-English error messages. So the computer illiterate has to ask on a forum like LQ, but it is more difficult, at least for me, to help if you don't understand the error-message, especially since the computer illiterate often has problems to give an accurate description of the error in the first place.

But that was still not my point.

@bobzilla, one of most valuable features of localised distributions is pre-configured and pre-tested keyboard layout and screen fonts + some patches that targets language bugs(like error handling non-latin characters in packer packages). This is main problem of software made by English speaking people: other languages are just postponed for distant future or worse - ignored completely(or even prohibiting it). Translation of some technical documentations(man pages, HOWTO's, etc) are only non-required, not requested, not necessary bonus, since those who are intended to use it can read English.

Difficult is not impossible. In this thread some people have figure out that "Ŀ¼" means "Catalog". It's not annoying but interesting provided that this kind of posts don't occur too often.

Anything that makes it more difficult to help someone will make it less likely that that person gets the help it needs, regardless if it is impossible or not.

If the asker could not use the system there would not have been the problem. What to solve then?

Of course, not using Slackware prevents having problems with Slackware. If that is your solution than I think that a discussion with you is rather pointless.

This is exactly your solution. You refuse to do useful things simple because it may introduce new problems.

"Doing nothing" is exactly what "Tao" requires. As I don't have the "Tao" religion I think that a discussion with you is rather pointless.

Don't twist words in my mouth.
As I have stated several times, I don't care in which language you run your systems (and also that this is not the main point of my statement, but you either wanted to ignore that or didn't understand), but you can't deny that it can make things more complicated, especially for people not being as computer literate as you seem to be. I even stated that it is a good idea to make Slackware fully UTF-8 compatible for people who want to do that. I posted my reasons for my opinion and I will also repeat it one more time extra for you: This is not my point.

My point was that I think that it is a bad idea to translate the Slackware specific tools, at least as long as there is no full translation of the documentation for them and as long there are no rules what happens if the translation is not working as suggested. As I stated, IMHO the downsides outweigh the benefits by far.
So actually, I do not It is quite the opposite. I talk about not doing things that I do not consider to be useful, just because the newly introduced problems outweigh the benefits, from my point of view.
This is what discussions usually are about, talking about things and discussing benefits/downsides.

@TobiSGD: In my opinion localizing the installer in one the highest priorities.

The reason is that for people who can't read English and with no outside help, the obstacle of not understanding what is displayed on the screen is near impossible to overcome, so probably they won't try Slackware, let alone adopt it.

Having said that, I understand your objections and will try to address it.

Let's keep in mind that if we use the 'gettext' method & tools for internationalization and localization, which is the most widely used, the language used to display the messages will depend on the value of $LANG.
(a) If set to en_US or en_US.utf8 the messages will be displayed in American English.
(b) if set to another supported locale and a translation in the corresponding language exist for some message, it will be displayed in that language.
(c) in any other case the 'original' message (in American English) will be displayed as a fall back.

You can check that with the tiny 'working example' I wrote to further present the internationalization and localization processes (see the PS I added at the end of the first post of this thread).

So if you want to help someone and need to see a message in English for that, just ask the OP to provisionally set $LANG to en_US then post the message in English.

The quality of translations will all depend on the rules we will set up and enforce. We will just need to be exacting and refuse incomplete or badly reviewed translations.

About the work involved for PV and the core team, I can't but agree that it should be lessen to a minimum.

It is very possible that the Slackware maintainer & contributors be only involved, if it is their wish:
(1) concerning initial internationalization, in reviewing for acceptation changes in scripts proposed by trusted individuals to ease further localization work and spot or mark the messages to be translated
(2) concerning localization, in including or updating the messages catalogs in the distribution
(3) concerning maintenance (mainly whilst cooking current) in writing the new scripts or changes in existing ones in an 'internationalized' way or delegating that task; then making aware the translation team that they should update the message catalogs.

They won't have to be involved in the translation work in any other way if that is not their will.

The scripts themselves will *not* be translated if we use the 'gettext' method & tools.

This stands as well for the main Slackware tools. For instance 'pkgtool', 'installpkg' and 'removepkg' are included in the installer so at least for that reason they will need to be localized.
In the same vein, 'setconsolefont' should be localized, though not included in the installer, because it will be executed during configuration after packages' installation.

As a side not some other files of the distribution could be localized using another method, for instance with one package par language as in the /kdei series.

About the translations in SlackDocs: hopefully they are under way. We could even get some synergy between the two projects if some editors of documentation in foreign languages would like to participate to the localization effort of Slackware too, and conversely in the future.

Oh, and I almost forgot: I hope it's not to late to congratulate you for beeing recently introduced to the 10k club

@Feyfre: Thanks for the link, I downloaded an iso of 'deepstyle'.

The installer is based on Slackware's with some files added. I noticed that the installation scripts are internationalized using an alternate method (not using 'gettext').

@all about UTF-8: we seem to agree that generalization of its usage is really needed, so it deserves a dedicated effort. Possibly as a sub-project?