Translation Project for ArchLabs

Hmmm using javascript and going through html. That may be your bridge. But where are you going to put your database. Git will probably be our best bet for that.

I help with Brazilian Portuguese!

I would like to know if it is possible to create a topic here or elsewhere to be able to show the advances in Brazilian Portuguese (pt-br), I think the visual question has to be exposed before being applied in text mode within the system, this is because a word has many variations and the menus can get large and thus lose harmony, see an example, modified a few lines to en, I tried simplifying and abbreviating the arguments.

Partially translated menu

1 Like

Hmmm, I would think we try to keep it together, then when other translators are stuck on how to translate a certain script, app, or menus, then it would be easier to see who to ask for that particular part of the project. Have to ask @Dobbie03 where we should put the data base for each language for easy access. Once we get that figured out, then we fill in the data base. I am hoping every thing that can be translated will be equal across the board.

2 Likes

Got it.
A single English word translated into Portuguese pt-br or pt-pt can have two or three words, I managed to leave the menu with the same aspect, but there are words there that can leave the menu very wide, in my language this menu (gif) was comprehensive and direct, It is also worth remembering that there is no translation for some words and this helps.

1 Like

@m.rogers, just create a new topic in https://forum.archlabslinux.com/c/technical-issues-assistance/translations

I leaning to a new repo, for now, for each language at the ArchLabs Github.

3 Likes

Ok!

Now doubts:

  1. Will AL provide a file or package so we can translate?

  2. Or where exactly should we search the system for this “X” file for translation?

  3. I imagine that we must follow a standard so as not to take risks and thus maintain a line of work that is really the same for everyone, example of preferences: Text or other specific editor, type of extension, format, type of sending, where to do and etc.

Well, time is not my greatest resouce at the moment, but I would like to sign up for the translation project.
I didn’t see anybody volounteering for translations to Italian, so I guess I will.
Of course I don’t mind to help with revision for the other languages (but, again, time is the enemy).
Would be great having the list of documents to be translated and a place to upload them once finished.
Please advise. Tnks

3 Likes

This is a team effort @pippo, so of course you’re welcome to join. Not only are we trying to things translated for each language, but how to implement the ability for someone to download and install packages in their language. English is the default, but obviously not everyone speaks English. So, the more help we can get, the better.

I am in agreement with @Dobbie03 that Archlabs git hub will be an excellent place to put all the source files. I can’t think of any other way of doing this. This way it stays in Archlabs, but we will have to keep tabs on updating. Maybe that’s an issue then again it may not be one. But @pippo brought up a good point. We need to list out what should be translated so that way we try to make it where every language is represented for each package.

1 Like

Guys DO NOT change this repo, but it will give you all some place to start the translating. Hopefully this will give you an idea of what packages you may want to start on. They are located here:

https://github.com/ARCHLabs/archlabs_repo/tree/master/x86_64

But DO NOT save your work here. We’re sitll trying to get that part figured out. Thanks Guys.

1 Like

Read this from @nate regarding translations.

1 Like

So, am I reading this correctly, that the actual packages installed, being scripted or coded will be translated, but the distro itself, unless we go through every bit of code where communication is required, will not. @nate is pretty much thinking the way we’re thinking of doing this. A fork called ‘language’ with a subfolder for each language.

It’s going to be a mix of the two, and likely some things may be out of our control

Things like pacli, al-hello, conkyzen, panel switcher, etc can use common files with translated text and can be located in /usr/share/archlabs/common/translations (or similar)

On the other side are things like WM configs, menus, etc… They will all need to be an individual copy of the original but with translated text only, for these we will do the same but instead of a script sourcing them at load time, they will need to be copied either manually, during install, or post install

2 Likes

That’s what I thought how this was going to go, but wasn’t 100% certain. Some of this will probably be fix as we go when we run into certain conditions. But it will be interesting since each language will bring its own issues. But we were thinking of using github for the data base under ‘language’ , possibly under AL’s repo. Trying to keep everything together and trying to keep the footprint small.

I’d rather keep things independant tbh as then we’ll get into the mess of needing dependant packages whilst still maintaining the first. Once we get something of actual substance I’ll deal with integrating it and updating as needed, my advice would be to just issue PR’s to the relevant repo to any changes made

1 Like

To those looking to actually get something started my advice for now without me getting something set up first would be:

  • Make a seperate text file and copy all the text to be translated into it
  • Choose a naming convention and stick with it (first come, first serve)
  • Use standard KEY=“Translated text” (ONLY for scripts, configs edit directly)
  • Some sources – pipemenus and scriptsconfigs and menus

Otherwise if no one else is able I can make a template of sorts for a few things to get started, however I’m not really up for walking multiple individuals through each step, if it can’t be figured out and difficult then simply make a text file with info regarding what its for and where each bit of text is for/from and I can get around to integrating it all.

Either way, cheers

1 Like

Good Morning,

I researched a bit to find a proper solution. My 2 Dollars on this topic is to extend my first approach of using a k-V File for each script/conf/whatsoever file and make use of a String Database. Here is an idea which would make some work to do, but which could offer a easier management.

  • Set up a simple Website where interested users can enter Translations
  • Set up a String Database like ol’ Mysql or [use favourite DB]
  • Replace “manually” every Description from scripts containing an english word or sentence with a CONSTANT
  • enter this constant into the Database, where each file to translate gets its own k-V table
  • foreach language available on this planet, create a column
  • Fun Part: aggregate stuff from participants
  • map translations to the considered files at installation time
  • Quality assurance possible only by community
    • lock tables after community has made it’s edits and review
  • create a process how to manage improvements/changes/upodates
  • create a process to create i18n-files which could be used to change the systems language, if someone chooses to go back to the original language.
  • so much more

This is a general approach, which I wanted to expose. This helps the devs to keep track of changes. Couldn’t that be added to this site?

Cheerio,
Semo

1 Like

https://poedit.net/ ?
I’ve used it in the past to translate a few projects, and that worked fine :slight_smile:

1 Like

@semo & @pitje I agree, let’s do it.
Actually, @Dobbie03? @nate? Any thoughts? I am all set now, but in a week time it will be ’ DEFCON 1 ’ at work and I will be chained to my desk for God knows how long.