search

labwc / labwc

A Wayland window-stacking compositor
https://labwc.github.io
GNU General Public License v2.0
1.62k stars 151 forks source link

NLS support - discussion #269

Open 01micko opened 2 years ago

01micko commented 2 years ago

There is whole world out there that needs to know about labwc.

NLS is an ongoing task. With every update:

Structural changes need to be made:

There's a lot more to it than a few dot points. I think it's necessary, at least to begin initial support now or soon.

johanmalm commented 2 years ago

Yes, great idea.

I don't know much about i18n myself, but suggested the following steps:

  1. Research and agree coding approach. I.e. do we use gettext()? And if so, how does that really work? What are the steps in producing po files.
  2. What's the scope? Menu files only, or all wlr_log messages, or something else?
  3. Do we setup a separate translation project to reduce the commit noise on labwc:master?
01micko commented 2 years ago
  1. Research and agree coding approach. I.e. do we use gettext()? And if so, how does that really work? What are the steps in producing po files.

Well, gettext is GNU, compatible with the project licence. IDK what else exists in the context of C. This tutorial is basically what I have done previously, albeit my programs are much simpler than labwc.

  1. What's the scope? Menu files only, or all wlr_log messages, or something else?

I'm thinking just GUI; at this point that's menus only. (EDIT: partly because of wide character support)

  1. Do we setup a separate translation project to reduce the commit noise on labwc:master?

Maybe until there are a few translations and everything is working well then squash some commits and merge back into the main line.

My 2 cents.

01micko commented 2 years ago

Other things -

Hopefully that takes care of Alpine and the BSDs.

01micko commented 2 years ago

Ok, some progress - sucsessfully generated labwc.pot

# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the labwc package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: labwc\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2022-03-12 10:22+1000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=CHARSET\n"
"Content-Transfer-Encoding: 8bit\n"

#: src/menu/menu.c:423
msgid "Reconfigure"
msgstr ""

#: src/menu/menu.c:425
msgid "Exit"
msgstr ""

#: src/menu/menu.c:441
msgid "Minimize"
msgstr ""

#: src/menu/menu.c:443
msgid "Maximize"
msgstr ""

#: src/menu/menu.c:445
msgid "Fullscreen"
msgstr ""

#: src/menu/menu.c:447
msgid "Decorations"
msgstr ""

#: src/menu/menu.c:449
msgid "Close"
msgstr ""
01micko commented 2 years ago

I have this working now.

it

I'm not issuing a PR at this stage because there's a couple of meson version dependant issues that need addressing. The show stopper is that I'm on meson-59.4 and the ${LOCALE}.po files generated always seem to end up with charset=ASCII and that fails to generate the gmo files with encoding errors. I believe meson >= 60.0 addresses this, but for a gettext implementation one would think that this would have been buitin from the start :confused:
I changed the charset to UTF-8 and that seems to work fine, at least for it, need to test de and es.

Instead I'll offer a diff of what I have so far (attached - updated):

i18n-diff-2.zip

The labwc.pot and three .po files are included that generate de.mo, es.mo and it.mo - just menus. Please excuse the bad translations if so! I used online Collins dictionary. And besides, this is for demonstration purposes.

01micko commented 2 years ago

de and es

de

es_fixed

Would be nice if I knew a shorter Spanish translation for 'Fullscreen' :laughing: But thats not as funny as my typo! in es. (fixed)

eli-schwartz commented 2 years ago

Do we setup a separate translation project to reduce the commit noise on labwc:master?

You could use something like transifex and then just merge the final translations in bulk into git immediately before release.

The show stopper is that I'm on meson-59.4 and the ${LOCALE}.po files generated always seem to end up with charset=ASCII and that fails to generate the gmo files with encoding errors. I believe meson >= 60.0 addresses this, but for a gettext implementation one would think that this would have been buitin from the start :confused:

AFAIK this behavior comes from GNU gettext's msginit program, which documents:

These values are set according to the content of the POT file and the current locale. If the POT file contains charset=UTF-8, it means that the POT file contains non-ASCII characters, and we keep the UTF-8 encoding. Otherwise, when the POT file is plain ASCII, we use the locale’s encoding.

01micko commented 2 years ago

AFAIK this behavior comes from GNU gettext's msginit program, which documents:

Yes, later on discovered that. It doesn't matter because the .po files need to be edited manually (or with po-edit or something) to fix encoding. EDIT: meson doesn't handle it well, but as said not to matter.

Just taking a look at transifex.

Thanks.

johanmalm commented 2 years ago

Thanks for moving this forward @01micko I haven't really got a preference as yet, but I'd like to add another option to the mix. If we're only translating the 7 menu entries, we could simply add some location entries in the menu.xml file, a bit like xdg desktop entry (https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s05.html) does for Name, Comment and so on. gettext() is generally intended for hard-coded strings in the C code, so considering that the strings we're intending to translate are actually designed to be read from xml-files, it does give us some options.

It would merely just be a matter of

It might potentially makes it easier for distributions and derivatives to extend the menus and include translations. Let's be honest... not many people would probably want the current hard-coded rootmenu :smile:

01micko commented 2 years ago

Well yes with the main menu this is true and I like your idea, but the window menus don't use xml and I don't think that they can.

BTW, gettext's scope is far more reaching than C. Many languages are supported including scripts and I believe XML based languages too. Even .desktop files.

Consolatis commented 2 years ago

the window menus don't use xml and I don't think that they can.

Actually they do, they just fall back to the internal hardcoded one. See docs/menu.xml.

01micko commented 2 years ago

My bad, was tired,

Anyway if only menus then can probably abandon gettext if the other method works.

Was a good exercise though. Now I know how to use meson with gettext :smile:

Consolatis commented 2 years ago

I think NLS would still make sense for manpages, default menu.xml and possibly comments in docs/rc.xml.all.

How to implement that.. I have no idea.

01micko commented 2 years ago

On further thought, I think my implementation (see diff in this post ) makes sense.

It does not solve the issue of documentation translations. I'm thinking maybe a 'docs' repo under the org for that.

A possibility with that infra structure in place, is that if a non-English locale is detected when meson is first called to configure the project then the docs[${LANG%_*}] repo could be added as a subproject - alongside the default docs. What do you think @eli-schwartz ? Possible with meson?

eli-schwartz commented 2 years ago

Why not just always translate it, and always include it as a subproject? Or if the concern is that many people don't care about offline documentation and don't want to clone lots of data etc. -- you can have a docs option that disables building the documentation at all.

At any rate, Meson allows you to inspect the value of options -- it doesn't allow you to inspect the contents of an environment variable that may not persist across reconfiguring.

johanmalm commented 2 years ago

@01micko I'm content with your proposal.

01micko commented 2 years ago

Moving forward with this soon.

01micko commented 2 years ago

@johanmalm

What is this translation like of labwc(1) from vivaldi translate? (They are Norwegian so shouldn't be too bad :sweden: <-> :norway: :thinking: - translation server is in Iceland :iceland: ).

labwc (1)

NAMN

labwc - En Wayland som staplar kompositören

SYNOPSIS

labwc [alternativ...]

BESKRIVNING

Labwc är en wlroots-baserad staplingskompositör för Wayland.

Det syftar till att vara lätt och oberoende, med fokus på att helt enkelt stapla fönster och göra några fönsterdekorationer. När det är praktiskt möjligt använder det klienter för tapeter, paneler, skärmdumpar och så vidare.

ALTERNATIV

-c Ange en konfigurationsfil med sökväg

-C Ange en konfigurationskatalog

-d Aktivera full loggning, inklusive felsökningsinformation

-h Visa hjälpmeddelande och sluta

-s Kör kommandot vid start

-v Visa versionnumret och avsluta

-V Aktivera mer verbosloggning

KONFIGURATION OCH TEMA

Labwc använder openbox-specifikation för konfiguration och tema, men stöder inte alla alternativ. Följande filer styr utseendet och beteendet:

Ekvivalenta XDG-baskatalogspecifikationsplatser hedras också.

Konfigurationsfilen och temat laddas om på mottagningssignalen SIGHUP .

Autostart-filen körs som ett skalskript. Detta är en plats för att ställa in en bakgrundsbild, starta en panel eller liknande.

Miljöfilen analyseras \<variable> = \<value> anger miljövariabler i enlighet därmed. Det rekommenderas att ange tangentbordsinställningar här, till exempel: XKB_DEFAULT_LAYOUT = gb. Se xkeyboard-config (7) för mer information. Observera att miljöfilen behandlas annorlunda med openbox där den helt enkelt kommer från innan du kör openbox.

SE Också

labwc-config(5), labwc-theme(5), labwc-actions(5)

johanmalm commented 2 years ago

Better than 90% correct I'd say. Just the odd word that needs tweaking.

01micko commented 2 years ago

My idea is that manpages and docs are going to be a user case thing so I don't see a benefit in incorporating into labwc. I envisage a separate repo, which I should start one day under my github account, say labwc-docs-i18n or something and when it's ready, transfer it to the org account.

The idea to install (or package) would be to have a meson routine getting the $LANG var from the users' environment (or for packagers just use the LANG direct).

Example: 

LANG=$LANG meson [options] build # if match isn't found, error

or for packagers

LANG=de meson [options] build # maybe LANG=all - have that as an option?

I know compiler and linker options can be passed to meson like that but @eli-schwartz is that possible with languages or is it better to make an option for meson? I suppose the LINGUAS file should be scanned so maybe an option is best.

Of course usual dependency checks (I'm thinking just scdoc should be fine) will be needed.

@johanmalm @Consolatis ?

johanmalm commented 2 years ago

Like the idea of a separate i18n repo. Not sure how that would work with meson

Consolatis commented 2 years ago

I am a bit skeptical about building stuff based on language detection on the build host. Most applications are not built on the same system that they run on (unless you use gentoo).

IMHO all language man pages should be built and the deciding factor for choosing one over the other would then be the language setting on the system that actually runs man.

Regarding the separate repo I don't have any strong opinion in either direction. Although.. for packaging it would likely be way easier if the different language versions are kept in the labwc repo itself.

01micko commented 2 years ago

The separate repo is for maintainability and less noise on the main repo. Using a subproject should be possible, but the conversion from .scd to groff may (I'm not too sure) need to be done locally, and that would depend on the current machine's locale.

When I get time I'll do more research on the subject, but I think it's a worthwhile investment.

eli-schwartz commented 2 years ago

I know compiler and linker options can be passed to meson like that but @eli-schwartz is that possible with languages or is it better to make an option for meson? I suppose the LINGUAS file should be scanned so maybe an option is best.

I already stated above that that is not possible. Compiler and linker options as environment variables is a universal standard, which Meson respects because support for it is built into Meson itself. Ad-hoc, completely arbitrary user-specified options do not have built-in support, and thus the only way to specify ad-hoc completely arbitrary user-specified options is by adding them to meson_options.txt

The separate repo is for maintainability and less noise on the main repo. Using a subproject should be possible, but the conversion from .scd to groff may (I'm not too sure) need to be done locally, and that would depend on the current machine's locale.

I'm... genuinely baffled as to why you think that conversion from .scd to groff, a matter of running a compiler (not a C compiler, but a documentation compiler) on an input file and producing an output file, would not work unless the current machine has defined the system locale to a specific value?

You simply have a bunch of *.scd files, one for each manual and each language, and you run the scdoc documentation compiler on each one, in turn, and produce output files based on the input files. This can be done on any machine that has, well, scdoc. It's not like scdoc will error out with the message "I refuse to work because you are trying to build a manpage for a language that isn't your current locale, and I bet you didn't want that, you silly goose".

Also, you need to produce all man pages for all languages. If you don't, then linux distros will distribute absolutely nothing and you've wasted all your time in writing and publishing documentation, so why did you even bother? However, the distros will helpfully submit a bug report to alert you to the fact that you should build the documentation so that they can distribute it. :)

There are zero consequences of distributing documentation for all languages, unconditionally.

You're talking a lot about putting it in a separate repo as a subproject for the sake of "less noise", but I don't understand what that has to do with which manual pages you then build. Either the subproject is used and people do build documentation at all, or it is not used and they do not build documentation at all. If they do build documentation at all, then they need scdoc, and once they have scdoc, there is no cost to building all of it.

And again, in order for this to have baseline minimum usability, all languages must be built when building a linux distribution, or the whole thing is a waste of time. It's built once by a distro, and then distributed to thousands of users, so that decision cannot be made at build time.

I have literally never once seen a project refuse to build any manual pages other than whichever one is the current system locale. Although I suppose there is always a first time for anything.

...

The only reason to implement such a thing at all is to save a handful of bytes of disk storage by not installing manuals for languages that a specific user won't use. But no one actually cares about this, it's a handful of bytes. And it significantly increases the complexity of the build while simultaneously introducing failure modes for the most common use case, which is distributors such as linux distros.

eli-schwartz commented 2 years ago

Like the idea of a separate i18n repo. Not sure how that would work with meson

You can simply add it as a subproject('labwc-docs-i18n'), and include it as a subprojects/labwc-docs-i18n.wrap file describing how to acquire it.

You can publish Github Releases manually uploaded attachments using meson dist --include-subprojects to create suitable release tarballs. These will contain the i18n repo inside, so that people building the release are guaranteed to get the same version that was used to generate the release, and without triggering network sandbox violations.