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 15 posts - 1 through 15 (of 23 total)
  • Author
  • #57629

    Transifex.com has some new applications up for translation

    Note to the dev team: I translated (to Portuguese PT-pt) hundreds of entries- some 50 of the Package Manager app description were left untranslated because I don’t think they are worth the extra work (they are basicaly localization packs to other languages, that portuguese users don’t usually need)

    Most of the applications regular users need are now localized (The translation of Package Manager’s categories was a great step, translating the app’s description was just a perfect idea!)

    Requests to the dev team:
    1. is it possible to put gksu up for translation on transifex? there’s a pt-br translation, but not a pt-pt one…

    2. Still missing – connman (CMTS) has localized files in it’s github; usb ejector, time&date
    Unfortunatly SpaceFM can only be further localized using a manually edited config file- I can dig up mine and provide it to the dev team (using it SpaceFM is 99% localized to pt-pt)

    3. Another idea: How about a small script, run after install, that asks if the user wants to download and install language packs for firefox-esr and libreoffice, and localized hunspell dictionaries? Or at least a mention that all that can/should be done using Package Manager after the install? That can be displayed if the user selects a language other than en…



    >>> put gksu up for translation

    If you do choose to “put them up for translation”, bear in mind that:

    1) the translations are split across 2 packages, “gksu” and “libgksu”

    2) the .po files in the source packages are “stale”. They need to be regenerated; as-is, their entries do not correnctly align with LineNos in the v2.0.2 gksu (and libsgku) program files.


    SpaceFM can only be further localized using a manually edited config file

    Is this “can only” statement valid?

    spacefm provides translations for 48 locales
    af ar bg bn_IN ca cs da de el es et eu fa fi fr gl he hr hu id it ja km ko lt ltg ml ms nb nl
    nn pl ps pt_BR pt ru sk sl sr sr@latin sv tr uk ur_PK ur vi zh_CN zh_TW

    and, spot-checking the content of the individual .po files, each seems to be well populated
    and each po file is an eye-popping seven thousand nine hundred lines long.
    for example: https://github.com/IgnorantGuru/spacefm/blob/master/po/es.po


    Since I had registered spaceFM as partly untranslated already, I tried to find out WHY these strings stay untranslated in antiX.
    My findings:

    1.) The .po file from SpaceFM Git-Repo reads (as well as the one decompiled from .mo file present in rinning instance of 19.3 antiX) the translations should exist on transifex already:
    Language-Team: German (http://www.transifex.com/projects/p/spacefm/language/
    But when trying to open this link in browser I get an 404 only.

    2.) Comparing the size of the .po translation file present in antiX 19.3 (decompiled from .mo using aCMSTS or manually) to the the translation file from Git-repo (both German version) reveals:
    — “Our” file only has 134,3k only whereas the .po file from repo has 217,5k filesize.
    — “Our” file has 5793 lines only, whereas the file from repo has 8568 lines.

    3.) The comparison using the command
    diff spacefm-from-recently-updated-antiX-19.3.po spacefm-from-git-de.po
    does show all the differences, but is that confusing at least to me I can’t make something useful of its output.

    4.) Manually searching and comparing the file contents of the .po files using a text editor (e.g. geany) reveals further insight, when examining random samples of translations found to be missing in running SpaceFM program.
    e.g.: At least some strings from “File Menu”, which is mostly untranslated in German, are actually present in .mo file, but not used when running. Some other strings are not present at all, and other files again are still untranslated (empty “msgstr” lines).

    The outcome is a mixture of different problems, preventing many english strings from getting translated in program usage.

    Any Idea which would be best practice this can helped?

    I believe, most pressing is: translated strings present in .mo file on system are not used when running.
    (Am I the only one feeling a déjà vu about this?)

    Next we should find the actual place the translations are created (since the transifex link found in the files is invalid as mentioned above), so we can add what is truly missing (fill in empty translation strings)

    Even when having checked all this in German language only, I presume the findings from other languages should be similar.

    I feel this program is important to fix soon, since a file manager is something most people will use on a every day basis.

    Note: People not familiar with handling .po and .mo files directly can easily decompile, inspect and test language files present in running antiX systems by using aCMSTS in recent 0.37a version.


    • This reply was modified 3 weeks, 6 days ago by Robin.
    • This reply was modified 3 weeks, 5 days ago by Robin.
    • This reply was modified 3 weeks, 5 days ago by Robin.

    Hello PPC and skidoo,

    My observations on the relevant issues raised here by the PPC are:

    I think that both gksu, SpaceFM and all the files available on the transifex website need or should be used in each update of antiX programs. If the developers do not search for the most recent translations on the transifex website, they (the translations) will never be included in the updated programs and, consequently, in antiX. What did I write, it seems to be something logical or not?!

    Translations for SpaceFM are also available at https://www.transifex.com/ignorantguru/spacefm/dashboard/.

    Translation into English of the SpaceFM file “session” is available at https://archive.org/details/configuracoes-e-traducao-pt-br-do-space-fm-com-a-lixeira-para-o-antix. There is the “session” file (default) without any customization and the “session” file with the trash and bookmarks. (I thank PPC for teaching me how to edit the “session” file)

    Some examples that the developers do not search for the most recent translations on the transifex website, are from the texts contained in the file “antix-all-desktop-entries_entxt”. @Zeh and I detected this in the review of the “.desktop” shortcut files contained in the “/usr/share/applications/antix” folder. Initially, I compared the text contained in each “.desktop” file with the texts contained in the “antix-all-desktop-entries_entxt” file in pt and pt-BR, and then we treated Zeh and me, only the files “. desktop “that needed special attention. In addition, I just copied the available texts “antix-all-desktop-entries_entxt” and sent them to @Xecure to make available via GitLab. Even some of these “.desktop” files have already been made available in antiX updates. I found that there were translations made by Zeh more than 3 (three) years ago and that they had not been used until March 27, 2020. All the work he did was not implemented in antiX …

    The idea of ​​the script that installs the translations is fantastic, another program that could be in the antiX ISO, at least in the full 32-bit and 64-bit version. I imagine how this script could be, it would have to check all the programs that the user has, identify the language used in the installed system and display a list with all the programs that can be translated, allow the user to select which or which programs he wants that the translations be installed. AntiX with a solution like this, will be raised to an even higher level. I also suggest having the shortcut icon for this “automatic translation installer” script, so with each new program installed, this script scans and displays which or which programs can receive translation packages.

    And here’s another suggestion:

    How can we help the team of developers to include all the English language files of the programs that still need to be translated on the transifex website?

    I want to collaborate/help, I know I can identify the script texts in the folder “/usr/local/bin”, assemble each text in English one under the other, of each program that needs to be sent to the transifex site in the topic list https://www.antixforum.com/forums/topic/list-of-antix-programs-that-are-yet-to-be-translated/.

    (Original text in Brazilian Portuguese)


    Olá PPC e skidoo,

    As minhas observações sobre os assuntos pertinentes, levantados aqui pelo PPC são:

    Eu acho que tanto o gksu, quanto o SpaceFM e todos os arquivos disponíveis no sítio transifex precisam ou deveriam ser utilizados em cada atualização dos programas do antiX. Se os desenvolvedores não buscam as traduções mais recentes no sítio do transifex, elas (as traduções) nunca entrarão nos programas atualizados e consequentemente no antiX. O que eu escrevi, parecer ser algo lógico ou não é?!

    Traduções para o SpaceFM estão disponíveis, também no sítio https://www.transifex.com/ignorantguru/spacefm/dashboard/.

    Tradução para pt-BR do arquivo “session” do SpaceFM está disponível no sítio https://archive.org/details/configuracoes-e-traducao-pt-br-do-space-fm-com-a-lixeira-para-o-antix. Tem o arquivo “session” (padrão) sem qualquer personalização e o arquivo “session” com a lixeira e os marcadores. (Eu agradeço ao PPC por me ensinar a editar o arquivo “session”)

    Alguns exemplos de que os desenvolvedores não buscam as traduções mais recentes no sítio do transifex, são dos textos contidos no arquivo “antix-all-desktop-entries_entxt”. O @Zeh e eu, detectamos isso na revisão dos arquivos de atalho “.desktop” contidos na pasta “/usr/share/applications/antix”. Inicialmente, eu comparei o texto contido em cada arquivo “.desktop” com os textos contidos no arquivo “antix-all-desktop-entries_entxt” em pt e em pt-BR, para depois tratarmos o Zeh e eu, apenas os arquivos “.desktop” que precisavam de atenção especial. No mais, eu apenas copiei os textos disponíveis “antix-all-desktop-entries_entxt” e os enviei para o @Xecure poder disponibilizar via GitLab. Inclusive alguns destes arquivos “.desktop” já foram disponibilizados nas atualizações o antiX. Eu constatei que haviam traduções feitas pelo Zeh de mais de 3 (três) anos atrás e que não haviam sido utilizadas até o dia 27-03-2021. Todo o trabalho que ele desempenhou não foi implementado no antiX …

    A ideia do script que instala as traduções é fantástica, outro programa que poderia estar na ISO do antiX, ao menos na versão full de 32 bits e 64 bits. Eu imagino como este script puderia ser, ele teria que verificar todos os programas que o usuário possui, identificar o idioma utilizado no sistema instalado e exibir uma lista com todos os programas que podem ser traduzidos, permitir que o usuário selecione qual ou quais programas deseja que seja instalado as traduções. O antiX com uma solução destas, será elevado a um patamar ainda maior. Eu sugiro ainda, ter o ícone de atalho deste script do “instalador de traduções automáticas”, assim a cada novo programa instalado, este script faz a varredura e exibe qual ou quais programas podem receber pacotes de tradução.

    E aqui vai outra sugestão:

    Como podemos ajudar a equipe de desenvolvedores a incluir todos os arquivos em idioma inglês dos programas que faltam ser traduzidos no sítio transifex?

    Eu quero colaborar/ajudar, eu sei que consigo identificar os textos dos scripts da pasta “/usr/local/bin”, montar cada texto em inglês um embaixo do outro, de cada programa que precisa ser enviado ao sítio transifex da lista do tópico https://www.antixforum.com/forums/topic/list-of-antix-programs-that-are-yet-to-be-translated/.

    (Texto original em idioma Português do Brasil)


    SpaceFM texts on antiX in pt-BR language.

    Textos do SpaceFM no antiX em idioma pt-BR.




    As far as I know, no one other than skidoo is maintaining the gksu sourcecode.
    skidoo it not involved with transiflex.
    skidoo does not create the .deb file(s) which are distributed via the antiX repositories.
    If the .po files within the source package are stale/broken, I would not know.
    As a monoglot programmer, I can only bracket to-be-translated strings with _(“”) inline within the code. From there, it’s up to someone else to take over handling the translation processing.

    I don’t know whether antiX will choose to use/distribute the forthcoming gksu release.
    This newer version is, comparatively, feature-limited.
    FYI, at the moment it looks like the new version will contain approximately only the translatable strings shown below.

    msgid "Not using locking for read only lock file %s"
    msgid "Not using locking for nfs mounted lock file %s"
    msgid "<b><big>Enter your password to run the application '%s' as user root</big></b>"
    msgid "Granting Rights"
    msgid "gksu needs a command to be run, but you specified none."
    msgid "Missing command to run."
    msgid "Unable to copy the user's Xauthorization file."
    msgid "Failed to fork new process: %s"
    msgid "Error creating pipe: %s"
    msgid "Failed to exec new process: %s"
    msgid "Error opening pipe: %s"
    msgid "Password: "
    msgid "<b>Incorrect password... try again.</b>"
    msgid "The underlying authorization mechanism (sudo) does not allow you to
              run this program. Contact the system administrator."
    msgid "sudo terminated with %d status"
    msgid "<b>You have capslock on</b>"
    msgid "\n"
    msgid "Run program"
    msgid "Run:"
    msgid "Opens a terminal as the root user, using gksu to ask for the password"
    msgid "Root Terminal"

    …and, upon release, probably all of these will be populated with strings already present within the earlier .po files.

    Is the presence / absence of LineNumbers significant, as seen in Robin’s screenshots?
    Would mismatched line numbers cause a given msgid to be ignored, at runtime?
    Do the files at/from transiflex even contain LineNumbers, or does transiflex discard/omit the numbers?



    some background:

    project was abandoned by its author back in 2016. S/he has remained incommunicado, except for a single “sprint” in 2018 which yielded the 1.06 (er v1.0.6) release.

    github.com/mati75 , the the maintainer of the debian package, is not actively “maintaining//fixing” the sourcecode.

    The debian-packaged spacefm “sourcecode” generates multiple separate packages.
    spacefm-common {—– contains the localization files

    On your system, check “apt show spacefm-common”
    AFAIK, the antiX developers do not (have not, to date) touch//alter//provide any spacefm localization files.

    Until / unless the antiX devs choose to “adopt” in-house packaging and redistribution of spacefm, maybe after submitting your updated translations you should (must?) contact the mati75 or submit a debian bug ticket to alert “sumbuddies” to the fact that updated translation sets are available?


    I do compile, and maintain, a private version of spacefm.
    If someone here offers to provide a set of improved spacefm .po files, I could publish a “higher versioned” spacefm-common .deb to gitlab for your testing. If all’s well in testing, antiX could adopt n redistribute solely that (spacefm-common) package.


    Is the presence / absence of LineNumbers significant, as seen in Robin’s screenshots?
    Would mismatched line numbers cause a given msgid to be ignored, at runtime?
    Do the files at/from transiflex even contain LineNumbers, or does transiflex discard/omit the numbers?

    on 1.) Referring to my observations: No. It doesn’t seem to make any difference whether they are present, correct or wrong, or even simply absent.
    I’m not quite sure in the moment whether this goes for the sort order of entries also, but I believe it does.

    on 2.) No. When creating .po files for aCMSTS itself I re-used files I had created and populated already, using them for later script versions in which were added some codelines (but no messagestrings) in different places, also some original messagestrings were moved to other places in the script. The now wrong line numbers in .po files didn’t make any difference on execution, gettext seems to ignore them completely.

    But a single character mismatch (maybe from correcting a typo in original messagestring in script) stops the show. Only for this specific string, of course.

    on 3.) The files from transifex have line numbers, at least the ones from SpaceFM. Other packages I didn’t check.

    The process of creating language files is relatively easy:

    First step is to mark the messagestrings in need of translation in source code correctly. (refer to the first attached screenshot) You can use other markers but the underline character when needed, but then you will have to modify the command for creating the .pot file correspondingly. The SpaceFM C source files seem to be marked already, using “_” . I’ll miss out all the stuff about the declaration of textdomain, textdomaindir, binddomain, which is present already in spaceFM.

    Second step is to create a .pot file (which is technically spoken nothing else but an empty .po file, containing only the list of msgids followed by the original strings, and empty msgstr eintries)

    The generation of the .pot file is specific to the programming language in use.

    Lets start with the file

    Since SpaceFM seems to be written in classical C the correct command would run:

    xgettext --keyword=_ --language=C --from-code=UTF-8 --add-comments --sort-output -o main-window.c.pot main-window.c

    There seem to be still some wrong entries within, but I don’t have not enough knowledge in reading C to be able to fix it within main-window.c or to decide whether they are actually incorrect.

    The created .pot file is the base file for creating all the language specific .po files, e.G. for pt_BR

    msginit --no-translator -l pt_BR -i main-window.c.pot -o main-window.c.po

    Now all the strings are to get translated. There must be some way to put the .po-files to transifex, but I don’t know anything about the method to be used for this by now. To do it at home one can use e.g. poedit, or simply edit the .po files in a texteditor. In order to create empty .po files prepared for different languages, simply replace the language identifier within the command.

    After the .po file once is filled in, you simply create the .mo file from it:

    msgfmt --output-file=main-window.c.mo main-window.c.po

    The resulting .mo files are to be stored in system folders


    that’s all. My aCMSTS script relies internally mainly on these techniques for manipulating existing .mo files in running antiX systems.

    The attached .pot and .po files are generated this way, this specific .po file is localised for pt_BR as example.

    Since this c program consists of many different source files, this procedure will result in a bunch of .pot files instead of a single one. I don’t know by now how to handle this problem, since I’ve worked on scripts only by now, consisting of a single file to be translated. We need a single spacefm.pot file in the end in order to create all the .po and .mo files for SpaceFM from. I’ll research on this, but if somebody has knowledge already he’d be welcome.

    As you can see from the above said, the process of generating language files in general is quite easy to handle, but it’s the mere number of .po files for all the languages which takes time when doing all the work manually. I will try to write a bash script for automatically creating all the different .po files from the single .pot file, and later on the .mo files from the filled in .po files. And yes, I’d like to provide the .po files we need for your new spaceFM version, if we find out how to overcome the problem of many C source files to result in one single .pot file.

    Further reading:

    • This reply was modified 3 weeks, 5 days ago by Robin.
    • This reply was modified 3 weeks, 5 days ago by Robin.
    • This reply was modified 3 weeks, 5 days ago by Robin. Reason: fixed typo

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

    hopefully that will be unnecessary.
    A package named “po-debconf” is installed as part of the “build-essential” debian metapackage and it (or one of the other packaging helper tools) should contain utilities to extract translatable strings from the *.c and *.ui and… to “create” and “regenerate” .po files automatically.


    The idea of ​​the script that installs the translations is fantastic, another program that could be in the antiX ISO, at least in the full 32-bit and 64-bit version. I imagine how this script could be, it would have to check all the programs that the user has, identify the language used in the installed system and display a list with all the programs that can be translated, allow the user to select which or which programs he wants that the translations be installed.

    Signed. This is something I have thought about for some time now also. To have such a feature in antiX would be great.


    Robin, install the “intltool” debian package if it is not already present on your system
    (AFAIK, “intltool-debian” package is preinstalled but “intltool” is not).
    These utilities might cover the much of the workflow.


    man intltool-extract
    man intltool-merge
    man intltool-prepare
    man intltool-update
    man intltoolize

    man xgettext

    I have been (still am) just grasping at straws here.

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


    [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

    The idea of ​​the script that installs the translations is fantastic

    I’m not “throwing cold water” here, just explaining a “sticking point” (an inherent problem):

    man dpkg-divert
    Bear in mind that the system expects to find the translation files in certain (specific) location.
    Each of the files installed to that location are provided by (installed by, “owned//managed” by) the package which installed it. With each apt update operation, any manually-edited (or injected via script) customized files are subject to being overwritten by copies of the same files provided by the associated package(s).

    In order to achieve a workaround, the “script” would need to create a dpkg-divert rule to protect each injected file from being overwritten ~~ e.g. 61 .po files for spacefm would necessitate 61 individual dpkg-divert rules. Multiplied by NN translation sets… I can’t guess how well (or poorly) this will scale. Parsing a lookup table containing hundreds (thousands?) of dkpk-divert rules — prior to installing EACH file of ANY package — might cause apt/dpkg operations to become uncomfortably slow.

    • This reply was modified 3 weeks, 5 days ago by skidoo.

    I would like and want to see the translations being applied in the right place so that everyone can access and use them.

    If the original English language texts from the programs below are added to the transifex, I will only need to copy and paste.

    Date and Time Settings Manager or (set_time-and_date), with script translated to pt-BR:

    Other Work Areas (desktop-session-menu-window), with script translated to pt-BR:

    Translation to en of the SpaceFM File Manager:

    These are isolated actions, I want to be able to help in the implementation of these actions in a concrete and permanent way to be able to benefit all users who speak pt-BR, but that goes for all other languages. If the development team is small, then it needs to grow. If today there are 10 (I don’t know what the correct number is), how about increasing it to 40?

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

    Dave also prepared the texts for “App Select” to be sent to the transifex. I have the texts in pt-BR ready, they were prepared by me and Luck Dias (he is one of the administrators of the MX Linux BR group unofficially, he does not participate in this forum, but whenever he can help me with the translations).


    (Original text in Brazilian Portuguese)


    Eu gostaria e quero ver as traduções sendo aplicadas no lugar correto para todos poderem ter acesso e utilizá-las.

    Se os textos originais em idioma inglês dos programas abaixo forem adicionados no transifex, eu só precisarei copiar e colar.

    Gerenciador de Configurações de Data e Hora ou (set_time-and_date), com script traduzido para pt-BR:

    Outras Áreas de Trabalho (desktop-session-menu-window), com script traduzido para pt-BR:

    Tradução para pt-BR do Gerenciador de Arquivos SpaceFM:

    Estas são ações isoladas, eu quero poder ajudar na implementação destas ações de forma concreta e permanente para poder beneficiar todos os usuários que falam pt-BR, mas isso vale para todos os outros idiomas. Se a equipe desenvolvimento é pequena, então precisa crescer. Se hoje são em 10 (eu não sei qual é o número correto), que tal aumentar para 40?

    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?

    O Dave também preparou os textos do “App Select” para serem enviados para o transifex. Eu tenho os textos em pt-BR prontos, foram preparados por mim e pelo Luck Dias (é um dos administradores do grupo MX Linux BR não oficial, ele não participa deste fórum, mas sempre que pode me ajuda com as traduções).


    (Texto original em idioma Português do Brasil)

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