Re: Configure languages for desktop in the shell?

Dennis Knorr <[email protected]> Mon, 20 Mar 2023 12:17:28 +0100
Newsgroups gmane.comp.kde.general
Message-ID <[email protected]>
Hi,
sorry for not following up for so long, but the last months were .. stressy.

Am 02.01.23 um 08:47 schrieb Duncan:
> A general answer that will hopefully point you in the right direction if
> nobody has an answer more specific to your situation...
>
> While I'm (effectively) English mono-lingual and haven't needed to deal
> with L10N much personally so my experience there is limited, I've found
> the kde admin guide very helpful in other areas, and expect it should be
> in this area for those who need it as well.  (That said, much of this was
> originally written for kde3 or earlier and updated for kde4 and kde/
> plasma5, so keep that in mind and for instance emphasize the newer XDG
> spec locations that kde/plasma5 and certainly the upcoming 6 are likely to
> use, over the older kde-specific ones from the 3 era, with 4 starting to
> transition to XDG but leaning toward the old ones and 5 mostly
> transitioned to XDG but with a few untransitioned exceptions.)


I am used to that. I am using KDE for some time now (like... almost 13
years?) :D.

> https://userbase.kde.org/KDE_System_Administration
>
> Plus some general observations:
>
> 1) KDE's config is (almost) entirely text-based, generally ini-style, so
> provided you can find the file (which the above admin guide should help
> with, that and a bit of hands-on experimentation has always done it for
> me), it's pretty much a given that you can text-edit it from the shell/
> text-editor/script.

The thing is though, i do not want to see all that visual stuff again,
once i figured out which ini files should be changed. I want to set it
to stone with some bash/ansible files and redo it after a reinstall of
my DesktopVM. And this is quite arcane and i know from the past, there
ARE sometimes efforts to support it with commandline tooling, but it was
never consistent.

I would also be fine if there's a default setting after installation and
the Setting Center (or whatever it is called) can create a diff after
configuration which can be imported.

But set the configuration manually again... is tedious.
Even if it is ini-files, because there are changes which are important
and there are ones which are not. (or are only important internally for
applications)


> 2) I /believe/ (with the initial caveat above...) that for the
> unconfigured user case, kde should default to system L10N defaults as set
> in the usual $LANG, $LANGUAGE, etc, environmental vars.  So if it's a case
> of just setting initial defaults that a user can reconfigure from later if
> desired, I'd be /quite/ surprised if (barring the occasional bug) just
> setting those correctly didn't "just work".

"just work" is for the standard configuration. But KDE _does_ provide
quite some configuration possibilities which it maintains also now for
quite a while. Why not support it with something which can be transfered
easily between machines? or with some cli/shell tooling?


> 3) Of course the kiosk mode discussed in the admin guide can (often) be
> used to prevent user modification of settings if that's desired, as well.
> (Again the caveat, but doubled in this case since I've neither l10n nor
> kiosk-mode-naildown experience.  I only know of kiosk mode from seeing it
> in the admin guide.)

Kiosk mode is only adressing it in part. I automate my desktop setup,
but i do not use a Kiosk. But automating screen resolution, notification
area and language should be doable without copying stuff from .config
from machine to machine (be it metal or VM).

Kind regards,
Dennis