Localization of antiX applications

Forum Forums General Software Localization of antiX applications

  • This topic has 22 replies, 5 voices, and was last updated Apr 26-3:36 pm by marcelocripe.
Viewing 8 posts - 16 through 23 (of 23 total)
  • Author
    Posts
  • #57737
    Member
    AvatarRobin

    the “script” would need to create a dpkg-divert rule to protect each injected file from being overwritten

    I believe the script isn’t supposed to overwrite any language files directly, as aCMSTS does on purpose (only temporarily, for testing translation stings in situ before transferring them to transifex, or providing a temporary fix for a user until a problem with a specific string is solved in a package), but manage the problem, inexperienced users will actually face, preinstalled programs in antiX, as libreoffice or firefox, come come up in English language only. Most *unexperienced* people wouldn’t expect they need to install (wouldn’t even know there exists) an additional language package, so they wouldn’t look for it. Non native English speakers are that used to things of all kind not being translated, they will accept it “as is” probably) So what the script — as I understand it from PPCs and Marcelos description — should do is to inform foreign language users about this important step they have to perform or — even better — directly present them the choice to install the set of language specific l10n-cc packages for these programs for the recent UI language (which is probably “their” language). It could boil down simply to an info dialog window containing a single question:

    Do you want to install the language packages in <UI-language> for
    the following programs (please select from list)
    [Listitem 1] [checkbox 1]
    [Listitem 2] [checkbox 2]
    [Listitem 3] [checkbox 3]
    ...
    If you chose not to install these language packages, 
    the programs above will come up untranslated in English language only.
    Abort ------------- Install
    

    The chosen language packages get installed then by means of standard apt installer, so no dpkg rules will get tampered with.

    Moreover (I don’t know whether this is possible) we could set the dependencies for any programs to be installed by user from our packageinstaller that way, the needed language packages for the *recent UI language* will get installed automatically along with the program package itself. There is no reasonable excuse for installing a program on a french UI in English language only, if the program provides french language support, letting it up to the user to find out he has to install some additional packages to finish the hat. (I remember well the times being a newbie myself, having some time worked with untranslated programs, not knowing the translation packages would have been two commands off my road only). At least the user should get informed somehow about the necessity to do so in case his UI language is set to something apart from English. (Imagine yourself being confronted with e.g. a Firefox popping up in Chinese language by default in antiX, without any comment, so you can understand how people feel) Not long before people were lost in our by then “English only” package installer, which problem is fixed meanwhile. How were they supposed to find the language package they’d need for e.g. firefox? (For you monoglot again this would have meant you would have found package installer in Chinese language only also, and yes, I’m aware you probably wouldn’t have needed to use packageinstaller at all.) I put it that blatant only to make aware of the importance of solving this problem for foreign language users (at least for the monoglots among them).

    Another way to cope with this could be an additional cheatcode at boot time (an additional choice in Boot menue) like
    Postinstall some language packs for chosen UI
    and a Help entry like
    This option will install language packs in UI language you have chosen from F2 menu for the following programs, which stay untranslated to your language otherwise: Firefox, Libreoffice, (Hunspell-)Dictionaries ... You will need an internet connection to perform this. Also you will be able to install these language packages manually later within Control Center still, if you chose not to let install them now

    P.S.: Explaining counter-arguments and inherent problems never means something like pouring cold water on sb’s ideas.

    • This reply was modified 3 weeks, 4 days ago by Robin.
    • This reply was modified 3 weeks, 4 days ago by Robin.
    • This reply was modified 3 weeks, 4 days ago by Robin.
    #57744
    Member
    Avatarskidoo

    $HOME/.local/share/fonts
    $HOME/.local/share/themes
    The XDG mechanism “knows” to look for these locations
    but, AFAIK, the XDG mechanism is not equipped to similarly consult
    $HOME/.local/share/i18n/locales/<subdirectories for each of the 479 supported known locales>

    Regardless “how” installed (by means of standard apt installer, or other), your localization files containing custom content will never be “seen” (and used) unless installed “to” the expected location /usr/share/…

    The chosen language packages get installed then by means of standard apt installer

    Repeating, rephrasing, an earlier point because it apparently has not yet been understood.

    During your envisioned “by means of standard apt installer” installation,
    upon first request to “install” a /usr/share/ file which is already present and owned by another package,
    in the absence of a dpkg-divert rule (or a dirty, ill-advised –force override) for that file
    your entire transaction (installation of your package) will immediately fail.

    #57756
    Member
    AvatarRobin

    upon first request to “install” a /usr/share/ file which is already present and owned by another package

    I don’t get the point. Sorry, I’m not that familiar with the behind the scenes of package management…
    Why should a file be owned by any other package already? Overwriting of files on update should only happen if tampering with .po files directly (like aCMSTS does, but this is meant for temporary use only). Here we ride another horse, I believe:

    For example, if I want to install firefox and libreoffice language package for German language, I ask apt to install
    firefox-esr-l10n-de
    libreoffice-l10n-de

    The same goes for Marcelo installing the Brasilian language packages or Wallon installing the French packages.

    Which other package could get affected by this, or which other package does affect the then installed language packages?
    And for a first approach it would be enough to make this easily available via suggested script for the languages Debian supports by default also, which is:
    cat "/usr/share/i18n/SUPPORTED" | grep UTF-8 | cut -d' ' -f 1 | cut -d'_' -f 1 | sort -u
    I’m aware there are not for all these languages language-packages present, but this is a detail to deal with on writing the code actually.

    I don’t understand why there is a folder in /home involved now, just to install official language packages.
    Maybe we are talking about two different approaches; please read carefully my previous posting.

    but manage the problem, inexperienced users will actually face, preinstalled programs in antiX, as libreoffice or firefox, come come up in English language only.

    The suggested script deals with the problem of not preinstalled official languagepacks for preinstalled programs in antiX resulting in not translated programs while running, e.g. live presistant. We probably won’t have the space in full ISO to put all of them into it, so we’ll have to find a workaround to make it easy for people to postinstall them, in particular for people not speaking english language.)

    I will try to write a bash script for automatically creating all the different .po files

    hopefully that will be unnecessary.

    Why not, it’s not that much work to do… about 50 lines are enough for this. Here you are 🙂 (file attached)
    Let me know whether it works for you on your system also, I have 32bit hardware only, which shouldn’t make any difference, but who knows. Try option -h first.


    Next step:

    Hmm… https://www.gnu.org/software/gettext/manual/gettext.html
    ^–v

    https://www.gnu.org/software/gettext/manual/gettext.html#Update-an-Existing-Translation-File

    [the following example would] concatenate the compendium file(s) and the existing PO, merge the result with the POT file and remove the obsolete entries (optional, here done using ‘msgattrib’):

    msgcat --use-first -o update.po compendium1.po compendium2.po file.po
    msgmerge update.po file.pot | msgattrib --no-obsolete > file.po

    So I’ll get going to find out how updating of existing .po files works, something I had not come across until now.
    Maybe @Xecure could help us to advance with this, I believe he is quite skilled on behalf of this already.
    But I’ll go on researching this anyway.

    So long

    • This reply was modified 3 weeks, 4 days ago by Robin.
    • This reply was modified 3 weeks, 4 days ago by Robin.
    • This reply was modified 3 weeks, 4 days ago by Robin.
    #57766
    Member
    Avatarskidoo

    For example, if I want to install firefox and libreoffice language package for German language, I ask apt to install
    firefox-esr-l10n-de
    libreoffice-l10n-de

    Yes, toward understanding, please do research this example.
    List the files intalled by each of these packages:
    dpkg -L firefox-esr
    dpkg -L firefox-esr-l10n-de
    and notice that ZERO instances of overlap (collision, conflict) exists between their installed files.

    libreoffice languagepack “packages” are each fairly large, so it’s unsurprising that files for each locale are split across manymany individual packages.
    If you compare libreoffice-core vs libreoffice-l10n-de, you will again notice: zero overlap

    For spacefm, the cumulative localization files were not regarded as being large enough to each merit its own, separate, package. The debian packager (mati75) did split the collective set of localization files into one separate (separate from the spacefm executable file) package… but for a different reason (i.e. without regard to size). Debian compiles the “spacefm” package, multiple times (for i386, for x86_64, etc.) and adds these architecture-specific packages into the download repository. For the “spacefm-common” package which provides the localizations, only one architecture-independent copy is needed in the repository.
    -=-
    Repositories, plural (testing, stable, xxyy-backports, oldstable, etc)
    multiplied by (?) eight supported CPU architectures
    multiplied by approx 30-thousand packagenames.
    -=-
    Availability of the spacefm-common package precludes the need to redundantly pack those files into
    40 “flavored” .deb files
    (testing, stable, xxyy-backports, oldstable, etc) x (eight supported CPU architectures)

    spacefm “depends on” spacefm-common.
    dpkg will refuse to install the former without the latter.
    Attempted removal of spacefm-common will forcibly remove spacefm.

    Debian packages, and provides for download on antiX systems, the spacefm-common.
    Please “dpkg -L spacefm-common” and note the myriad files it provides (installs, “owns”)

    An in-house maintained spacefm-common package, distributed via antiX repository
    could simply declare a higher package version number and would be recognized
    as “the same owning package” ~~ all the localization files could be injected, en masse, via “regular apt upgrade”.

    dpkg “knows” each and every one of these installed files, and guards them from being overwritten by any package other than the one which installed ’em.

    Hi. I made a superior ES translation file for spacefm.
    ^—— If spacefm-common LACKS a localization file for that particular locale, it could be bundled into a new (call it “spacefm-common-extra” for example) package and installed without conflict ~~ identical scenario to the separate firefox-esr “translation packs”. If, however, an installed by spacefm-common es_ES file already exists… any other package which attempts to replace it will be stonewalled.

    https://packages.debian.org/buster/all/spacefm-common/filelist
    /usr/share/locale/es/LC_MESSAGES/spacefm.mo
    Hi. Thats’s great! To have your file added into the distribution, you will (must) now…
    https://packages.debian.org/buster/spacefm-common
    ^—v
    https://tracker.debian.org/pkg/spacefm
    …contact the maintainer of the spacefm-common package

    #57767
    Member
    Avatarskidoo

    I don’t understand why there is a folder in /home involved now, just to install official language packages.

    Right, there’s no such folder involved.
    If such was, if fact, supported… or if we could (but I don’t know how)
    alter the “xdg” search path so that we could add per-user custom “translationpacks”
    in the same manner that we can override stock desktop themes… we could thereby sidestep the “dpkg conflict”

    The suggested script deals with [..] not preinstalled [..] languagepacks for preinstalled programs

    on a dpkg -managed system:
    1) Adding supplementary “missing” files is fine, no problem.

    2) Attempting to replace//overwrite any pre-installed (stale, half-empty, bad translation strings) localization file will fail (sans a dpkg-divert rule) unless injected via some means other than .deb installation… and any such file which is manually edited (or is injected via means other than dpkg) is subject to being overwritten during upgrade of the package which originally (pre)installed it.

    #58082
    Member
    marcelocripemarcelocripe

    I wrote:
    I have the “inxi-gui” texts in English prepared to be sent to the transifex, who has permissions and access can do this?

    Rectifying:

    The program “inxi-gui” or PC Info (in the menu in English), the transifex site has the file “inxi-guipot”, but it is not translated into antiX 19.3 in pt-BR and pt. (Thanks Xecure for alerting me about this).

    The question now is, why are not all the translations contained on the transifex site being used?

    marcelocripe
    (Original text in Brazilian Portuguese)

    ———-

    Eu escrevi:
    Eu tenho os textos do “inxi-gui” em idioma inglês preparados para ser enviado para o transifex, quem tem permissões e acesso pode fazer isso?

    Retificando:

    O programa “inxi-gui” ou PC Info (no menu em inglês), o sítio transifex possui o arquivo “inxi-guipot”, mas não está traduzido no antiX 19.3 em idioma pt-BR e pt. (Obrigado Xecure por me alertar sobre isso).

    A dúvida agora é, por que não estão sendo utilizados todas as traduções contidas no sítio transifex?

    marcelocripe
    (Texto original em idioma Português do Brasil)

    #58083
    Member
    XecureXecure

    I feel I am repeating myself with this. BUILDING PACKAGES TAKES TIME. anticapitalista is waiting for more translations to be finished, and then package the new versions of packages that will include the translations. Building tens of packages every week only because one language has changed three lines is wasting time. Language translations don’t magically appear from transifex to your system. Each .po file for every language needs to be donwloaded, they have to replace every translation file, be it that they were translated or not, they each have to be compiled to machine ready .mo translations, the new package has to be build for 2 architectures (i386 and amd64) for 3-4 different repos (stretch, buster, bullseye and maybe testing/sid) and they have to be uploaded to the official repo.

    If someone is ready to voluntarely do this, I am sure anticapitalista will appreciate the effort, as he is almost soloing everything himself.

    If I don’t get distracted, I will write an article for people to learn how to colaborate with GIT, how to build packages and how to set up an easy way to build for various architectures and debian versions using sbuild.

    #58102
    Member
    marcelocripemarcelocripe

    Xecure,

    I do want to learn.
    If I can understand each step and do everything correctly, I will be able to collaborate with antiX, not only in my language (pt-BR), but in all the languages contained in this precious operating system.

    marcelocripe
    (Original text in Brazilian Portuguese)

    ———-

    Xecure,

    Eu quero sim aprender.
    Se eu conseguir compreender cada etapa e realizar tudo corretamente poderei colaborar com o antiX, não só em meu idioma (pt-BR), mas em todos os idiomas contidos neste precioso sistema operacional.

    marcelocripe
    (Texto original em idioma Português do Brasil)

Viewing 8 posts - 16 through 23 (of 23 total)
  • You must be logged in to reply to this topic.