Translations in packages

Forum Forums antiX-development Translations Translations in packages

  • This topic has 16 replies, 5 voices, and was last updated Sep 23-5:00 pm by Xecure.
Viewing 15 posts - 1 through 15 (of 17 total)
  • Author
    Posts
  • #67608
    Forum Admin
    anticapitalista

    Should antiX packages (debs) include all localised po/mo files from Transifex or only those that are 100% complete?
    Transifex has 55 languages.

    Philosophers have interpreted the world in many ways; the point is to change it.

    antiX with runit - leaner and meaner.

    #67609
    Member
    Xecure
    Helpful
    Up
    0

    I vote for only using 100% translated.

    Transifex doesn’t give a “over 50% translated”, so the best option is 100%. We save space with barely translated .mo files and give a better impression (if an app is barely translated, it seems like a half-assed effort).

    OT-1: Did the script to convert .po to .mo at build time help at all?

    OT-2: Would it make it easier (for maintenance) to only have 1 package with all antiX localized .mo files? You would only need to package translations once (for a possible “antiX-programs-l10n” package), updating only one package, instead of having to update every antiX package with newer/updated translations. And also English language speakers can remove the translations package to save space.

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

    antiX Live system enthusiast.
    General Live Boot Parameters for antiX.

    #67613
    Forum Admin
    anticapitalista
    Helpful
    Up
    0

    OT1 – I haven’t tried it yet.
    OT2 – The ‘problem’ with this is that the package can only be removed for English users. Someone might (rightly) complain that this is unfair for example to French users as they cannot remove any unwanted localised mo files. As a result it is ‘mean and lean’ for English users only.

    Philosophers have interpreted the world in many ways; the point is to change it.

    antiX with runit - leaner and meaner.

    #67616
    Member
    Xecure
    Helpful
    Up
    1

    OT2 – The ‘problem’ with this is that the package can only be removed for English users. Someone might (rightly) complain that this is unfair for example to French users as they cannot remove any unwanted localised mo files. As a result it is ‘mean and lean’ for English users only.

    I will try to set up a source project from which to create one package for each language “antiX-programs-l10n-<language-code>” at build time and share it with you. The only maintenance needed would be for this source project (manually replacing all of the .po files for the ones directly downloaded from transifex, as I don’t know how to do this automatically via transifex-cli), which would automatically build all language packages at build time.

    antiX Live system enthusiast.
    General Live Boot Parameters for antiX.

    #67617
    Member
    marcelocripe
    Helpful
    Up
    0

    Hello anticapitalista and Xecure,

    I need to remind you that several files are not in use, I imagine that’s why they are locked in “anti-capitalist/antix-development/”. These files do not allow them to be translated. Due to the various files with this status, the Transifex statistic is unreliable and the translation percentage index is not correct. In Portuguese (Brazil) (pt_BR) there will ALWAYS be “230 untranslated entries”, as they refer to these files that are blocked. Any MX Linux file that is also not in use will increase this erroneous stat.

    – – – – –

    Olá anticapitalista e Xecure,

    Eu preciso lembrá-los que vários arquivos que não estão em uso, eu imagino que seja por isso que estejam bloqueados em “anticapitalista/antix-development/”. Este arquivos não permitem que sejam traduzidos. Devido aos vários arquivos com este estado, fazem a estatística do Transifex não serem confiáveis e o índicie de porcentagem de tradução não ser correto. Em Portuguese (Brazil) (pt_BR) SEMPRE irão existir “230 entradas por traduzir”, pois são referentes a estes arquivos que estão bloqueados. Qualquer arquivo do MX Linux que também não esteja em uso fará aumentar esta estatística errônea.

    #67619
    Member
    Xecure
    Helpful
    Up
    0

    @marcelocripe, when an administrator in transifex downloads the translations for a resource (a specific program), they are given 3 options:
    1. Only download 100% completed translations for this resource (for antixccsh, for example, only the languages that have 100% of antixccsh strings translated).
    2. Only download 100% reviewed translations (what we badly call “blocked”) for this resource.
    3. Download all translations (even if they are 0% completed).

    So, as long as the resource has a language showing “100% translated”, if option 1 is selected, it will send a .zip link to the administrator containing all 100% translated languages .po files.

    antiX Live system enthusiast.
    General Live Boot Parameters for antiX.

    #67621
    Member
    marcelocripe
    Helpful
    Up
    0

    … when an administrator in transifex downloads the translations for a resource (a specific program), they are given 3 options:
    1. Only download 100% completed translations for this resource (for antixccsh, for example, only the languages that have 100% of antixccsh strings translated).
    2. Only download 100% reviewed translations (what we badly call “blocked”) for this resource.
    3. Download all translations (even if they are 0% completed).

    Is this all automated (or automatic)?
    Does the administrator just choose what he wants to be downloaded?

    Isso tudo é automatizado (ou automático)?
    O administrador apenas escolhe o que ele quer que seja baixado?

    #67622
    Member
    Xecure
    Helpful
    Up
    0

    Is this all automated (or automatic)?
    Does the administrator just choose what he wants to be downloaded?

    As far as I know, the only other alternative is to download one language at a time (very time consuming, as anticapitalista mentioned, having to do this for each of the 55 languages).

    What I have seen from the interface, I would normally select the resource, then in the top options select to download translations (for that resource), and then get the options explained above (100% translated, etc. etc.)..

    antiX Live system enthusiast.
    General Live Boot Parameters for antiX.

    #67625
    Forum Admin
    anticapitalista
    Helpful
    Up
    0

    Getting the po/ts and some txt files from transifex for each package is easy to do.
    Converting them from po to mo or ts to qm (qt apps eg iso-snapshot) is also easy, though sometimes time consuming.
    The difficult part is trying to sort out the desktop files and window manager menu/tray files as they are in a ‘bulk’ package.

    There could/should be a better way to set up the window manager files at transifex.

    Philosophers have interpreted the world in many ways; the point is to change it.

    antiX with runit - leaner and meaner.

    #67633
    Member
    Robin
    Helpful
    Up
    0

    Hello anticapitalista,

    Someone might (rightly) complain that this is unfair for example to French users as they cannot remove any unwanted localised mo files. As a result it is ‘mean and lean’ for English users only.

    This is true, but I remember somebody mentioned her on the board a method to remove all unwanted (unneeded) languages, I believe it was skidoo. If this process could get automatised by means of a script, the single package wouldn’t be a problem in most cases. Well, it could be problematic still on machines with very low resources during the installation and cleanup process, until all unneeded languages are removed again. So this is the second best alternative in my eyes. Best would be:

    one package for each language “antiX-programs-l10n-<language-code>

    Yes, this sounds great. One language per package antiX-l10n package. This prevents to overcharge systems (e.g. live systems) with small memmory amount, which can’t handle the intermediate blast of language files until a script has cleaned up.
    So when it is about mean and lean, it should be one language per package, as Xecure has proposed.

    About the “100% ready for use“ information on transifex: This statement propagated by their site is completely nonsense. The gettext system works not this way, and I talked about this with them already. They agreed, and will probably try to change it to meet the correct way gettext utilises. If you have e.g. the language fr_BE, there are only few differences to some of the strings in fr. It is nonsense to fill them all in separately in both languages, and gettext doesn’t even expect this. Who should check the consistency between all the identical entries when some of them have to get corrected once? This is unmaintainable.
    The correct way is: All languages with two character language identifier need to be translated to 100% (except theoretically for English expressions used in other languages also, but this can be neglected), while all the languages with four significant character language identifier need to have filled in only strings which differ from the two character code, to be ready for use. So the two character language code serves as a base for all languages within its language group. This is important when installing the packages also: fr_BE contains (should contain) only the delta to fr and expects the fr files to be installed as well. The same mechanism is true for de, de_AT and de_CH (in case somebody bothers to fill them in at all.) and all the other languages as well. It is difficult to determine whether or not a four sign. char. id. code language is ready for use or not by now. (Apart from pt_BR, where literally all strings differ from pt, but this is an exception.) The developers at transifex will possibly (hopefully) add a checkbox aside of the strings (just like the ones for massive actions) so translators can mark them one by one or altogether as “no need of translation”, which results in languages to be reported as 100% ready for use even if most strings are empty on purpose. (Translators will also be able to uncheck them again and fill in something in case they feel it to be necessary.) Until this feature will be implemented once we have simply to guess whether or not a four sign. character language is ready for use. This actually can only get answered by people speaking the language, and therefore the addition of the checkboxes mentioned, at transifex, is that important.

    Robin

    #67635
    Member
    Xecure
    Helpful
    Up
    0

    The difficult part is trying to sort out the desktop files

    This is a nightmare, as you need to somehow replace contents for all .desktop files and it only seems to be possible manually. I opted for including the Name and Description inside the scripts to be translated and copy it over from there for the corresponding desktop file. Though that would be a big effort for the large amount of them in antiX.

    The difficult part is trying to sort out [..] the window manager menu/tray files as they are in a ‘bulk’ package.

    Would it be easier to have a “txt” file with variables, like

    TERMINAL_ENTRY=$"Terminal"
    FM_ENTRY=$"File Manager"
    ...

    and then source it in a script, to then create the menu file from a template.

    cat > "$PATH_TO_MENU" <<ICEWM_TEMPLATE
    prog "$TERMINAL_ENTRY" ${ICON_THEME}/48x48/apps/terminal.png desktop-defaults-run -t
    prog "$FM_ENTRY" ${ICON_THEME}/48x48/apps/file-manager.png desktop-defaults-run -fm
    separator
    [...]
    ICEWM_TEMPLATE

    and generate the menu from it. This could replace the default English menu the first time desktop-session runs (as it detects the language) and could also launch when the user changes language/locale (when launching a hypothetical locale-antix script with GUI that I may or may not be developing).
    This way you shouldn’t need to to fixup 4 menus per language (one per icon theme), and reduce the maintenance costs (time and space).

    • This reply was modified 3 weeks, 3 days ago by Xecure. Reason: fixing code quotes

    antiX Live system enthusiast.
    General Live Boot Parameters for antiX.

    #67653
    Member
    marcelocripe
    Helpful
    Up
    0

    The difficult part is trying to sort out the desktop files and window manager menu/tray files as they are in a ‘bulk’ package.

    I imagine the “bulk” files are antix-all-desktop-entries_entxt and make-wm-menuspot. The antix-all-desktop-entries_entxt should go a long way, extracting the name and comment of each program to build each .desktop file from the 55 languages.
    It would be easier if Transifex could have the models of the structure of each program’s .desktop file, so translators would only have access to their respective translation language for the name, comment and any other input that is needed.

    What we can’t do is the way Jerry is doing on the MX Linux forum, he asks for help translating a .desktop file, if a translator sees the topic the file will receive the translation, if the translator doesn’t see the topic the .desktop file will not receive the translation.

    but I remember somebody mentioned her on the board a method to remove all unwanted (unneeded) languages, I believe it was skidoo.

    or

    One language per package antiX-l10n package. This prevents to overcharge systems (e.g. live systems) with small memory amount, which can handle the intermediate blast of language files until the script has been cleaned up.

    Both solutions have advantages and disadvantages. But it looks like the workload would be much smaller with the second option, I imagine what the second option “antiX-programs-l10n- <language-code>” would be like, I think at least the gazelle-installer (antiX installer) , top level menus and application menus (.desktop files) would need to be translated, all other application programs available in antiX would receive the translation via the language-specific package of “antiX-programs-l10n- <language-code> “. This method would greatly decrease the size of the ISO, on the other hand, we would need to have the “Welcome screen” (translated to all 55 languages) advising on how to connect to the internet and how to install the translation package (at least this information) and then the screen antix-translation-info. And a personal concern is the need or possibility to install this package “antiX-programs-l10n- <language-code>” without internet access. I would put on the USB device prepared with Ventoy, the antiX ISOs and the offline translation package for antiX to remain a “Swiss army knife”.

    I hope my suggestions can be helpful.

    – – – – –

    The difficult part is trying to sort out the desktop files and window manager menu/tray files as they are in a ‘bulk’ package.

    Eu imagino que os arquivos em “massa” sejam antix-all-desktop-entries_entxt e make-wm-menuspot. O antix-all-desktop-entries_entxt deve dar um trabalho gigantesco, extrair o nome e o comentário de cada programa para construir cada arquivo .desktop dos 55 idiomas.
    Seria mais fácil se no Transifex pudesse ter os modelos da estrutura do arquivo .desktop de cada programa, assim os tradutores teriam acesso apenas ao seu respectivo idioma de tradução para o nome, comentário e qualquer outra entrada que for necessária.

    O que não podemo fazer é a forma como o Jerry está fazendo no fórum do MX Linux, ele pede ajuda para a tradução de um arquivo .desktop, se um tradutor ver o tópico o arquivo receberá a tradução, se o tradutor não ver o tópico o arquivo .desktop ficará sem receber a tradução.

    but I remember somebody mentioned her on the board a method to remove all unwanted (unneeded) languages, I believe it was skidoo.

    ou

    One language per package antiX-l10n package. This prevents to overcharge systems (e.g. live systems) with small memmory amount, which can’t handle the intermediate blast of language files until a script has cleaned up.

    Ambas as soluções possuem vantagens e desvantagens. Ma parece que a carga de trabalho seria bem menor com a segunda opção, eu imagino como seria a segunda opção “antiX-programs-l10n- <language-code>”, eu penso que ao menos o gazelle-installer (instalador do antiX), os menus de primeiro nível e os menus aplicativos (arquivos .desktop) precisariam estar traduzidos, todos os outros programas aplicativos disponíveis no antiX receberiam a tradução via o pacote específico de cada idioma do “antiX-programs-l10n- <language-code>”. Este método iria diminuir bastante o tamanho da ISO, por outro lado, precisaríamos de ter a “Tela de Boa-Vindas” (traduzida para todos os 55 idiomas) orientando sobre como realizar a conexão com a internet e como instalar o pacote de tradução (no mínimo estas informações) e em seguida a tela antix-translation-info. E uma preocupação pessoal é a necessidade ou a possibilidade de instalar este pacote “antiX-programs-l10n- <language-code>” sem acesso à internet. Eu colocaria no dispositivo USB preparado com o Ventoy, as ISOs do antiX e o pacote de tradução off-line para o antiX continuar a ser um “canivete suíço”.

    Eu espero que as minhas sugestões possam ser úteis.

    #67661
    Member
    zeh
    Helpful
    Up
    1

    I don’t know what are the technical implications of doing things in one way or in a different way, so I just give a plain user opinion, for how unreasonable it may be from the technical point of view.
    I think it’d be worth to have antiX localized in any language that is “almost” totally translated. For “almost” I’d say 90% e.g. If someone gets a system translated at 90% (it could be 85% or 80% or any limit the dev team whishes) it’d be mostly understood by a speaker of the given language and it could be a way of getting someone to volunteer to finish the translations.
    Also, there could be a message somewhere, I guess, letting people know which languages are translated at more than 60% or 70% and that when those languages reach xx% translated they would become available for localization (again, as a way of inviting prospect translators).

    • This reply was modified 3 weeks, 3 days ago by zeh.
    #67692
    Member
    Robin
    Helpful
    Up
    0

    Again on the 100% question.
    Well, I should append to what I have stated above already: There is an alternative to the ‘correct’ gettext way of handling four significant character identified languages. But this will bloat the files and directories unnecessarily: Just copy any strings found to be empty in a four character language from its two letter base language to it. And do this for every single of them, which has at least one string in it. Gettext would do just the same, using any missing strings from there on runtime, so actually we wouldn’t need to do this. This bloats files only, and this is not mean and lean anymore then. But it could probably get automated by applying a script on the files after downloading them from transifex. I would never perform this string duplication (multiplication?) on transifex diretly for maintenance reasons. Better to have a string to be fixed in a single place than to have to check all its unnecessary copies also.

    What I wanted to underline: Four letter languages are to be considered as 100% ready for use always, as long as there is a single string within it. (Until we see the checkbox mentioned above on transifex so translators with their specific knowledge of the language can decide…)

    #67699
    Forum Admin
    anticapitalista
    Helpful
    Up
    0

    At the moment, translations >=80% are included in the vast majority of packages

    Philosophers have interpreted the world in many ways; the point is to change it.

    antiX with runit - leaner and meaner.

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