Translations and virtual touch keyboards - tracking localization

New squeekboard release 1.8.0 will hit the repos in a day or two, and contains the ability to choose the terminal layout prototype at will.


Terminal seems to have only added “actions” view, it seems. Do I understand this right: only this keyboard for terminal and these buttons are available only in terminal? As I can’t seem to find reason why a different keyboard is for terminal, two questions:

  • For languages: will this view be added to other language keyboards as well automatically - as it would be difficult to go to another keyboard just to type a special character on a filename that’s not included in the terminal version?
  • For actions: why not add it to all, even if not using terminal, as they seem useful buttons and are out of sight if not needed? Or: why have two separate keyboards (normal and terminal versions) of each language?

I’m not sure if I understand your question, but: a separate layout was easier to implement at the moment. Those buttons are available in any layout you decide to create, but they may not be accepted upstream if they are used in any other layout.

This was planned by the design team, and will likely happen, but I don’t know how exactly yet.

The keyboards are very cramped already, languages with more than 30 buttons are already troublesome to support with this amount of space. The majority of users will never need those buttons, and for the rest the layout will switch automatically for the terminal (patches in vte will take care of a lot of terminals).

I think were switching different terms, therefore misunderstanding… I’m still under the impression that there will be only one (language) terminal keyboard without possibility to use chosen language version that includes the same “actions” layout view. I am worried, that the action view will not be available in normal keyboards with other apps than terminal, because it’s been talked that terminal has a separate keyboard. And, because the terminal keyboard doesn’t seem to have language versions, it won’t include special characters of user’s chosen language, which would make it problematic with file names in terminal. Does this make a little more sense?

The terminal keyboard layout is intended to eventually work with any language (reality might verify that).

When it comes to applications that are not terminals, then you can bring up the layout manually in 1.8.0.

From another conversation:

… something for next versions.

For those who want to make this happen, there’s , which supports modifiers. Your move can be to:

  1. Add a control key to the layout
  2. Test/review the MR so that I can be sure it’s safe for inclusion

Latest observations…

  • Chatty has updated its source and only two languages are at 100%, so updates are needed. Phosh had a good start last year but there is much to update there too for those marked with blue and white.
  • @dcz was asking about layouts and several languages need people to tell what is the normal layout of their (touch)keyboards. Especially non-latin languages should have input methods. Also, don’t forget, you can test in emulator and give feedback.
  • The Transifex site (and probably the software that’s available) has updated with new features. Pure Maps there has a small source update as well.
  • Zanata seems to have updated too: “The Zanata server at will enter maintenance mode on Tuesday March 3 between 02:00 and 03:00 UTC. After this, the server will be migrated to a new location so expect noticeable downtime. Please be aware that the server will stop accepting new projects. Existing projects will continue to exist and operate as usual. If you are interested in running your own Zanata server instance, or contributing to the further development of the Zanata platform, please check out the source repository at: For questions regarding outages or support for this server please contact the Red Hat OSPO Comminfra Team

(Grayed out external projects were not updated this time - not much changed)
(edit, update 10.2.: added Polish keyboards, that had appeared - sorry about missing that)

@dcz I see in the above table that for Greek the keyboard says “yes/-” Does this dash means that the portrait/wide mode is not done? If yes, what should be done for this? Any directions? I want to complete the Greek part if this is missing.

Yes, portrait layouts were added later and only some languages have that.

To add a portrait layout, you need to take a look at the tutorial

The landscape layout would be called gr_wide.yaml, not mentioned in the tutorial yet (updates to the tutorial welcome, it’s in the docs directory).

New delayed 1.9.0 release of Squeekboard arrives in a few days.

The release is based on a big new feature: when the application supports it (GTK), then text is sent as text instead of key presses. The change would have gone live earlier, but it turned out deleting text not as key presses ended up fundamentally broken and needs to get redesigned.

Other features:

  • Fixed glib critical when switching layouts
  • Fixed minor memory leaks when switching layouts
  • New Polish language layout
  • Fixed greek layout
  • Better key locking
  • Less leaks
  • Tweaks in terminal layout
  • Better emoji layout

Thank you to all contributors and reporters!


All languages dropped :part_alternation_mark: to low percentages in translations as phosh translationfiles in Zanata just updated :astonished: with several entries - it might take you all of 20 minutes to do them all :sweat_smile:. It should be suggested that updates should be done soon / this week :spiral_calendar:, as the server and service is due to change :electric_plug::computer: and no one want’s to have last minute translations go missing due to the move :truck: :articulated_lorry: :truck:.

I’d hope and expect that someone will a post about when to stop using Zanata, when to move to new system, where to find manuals, how to ask for context on strings, how to decide on accepted translation, if there are any timetables/cycles for updates, how to get additional languages added, how to handle group effort and quality control, automatic/machine translations, anonymity settings, policy on using shaping and labels, rate limits, commenting or changing source, will there be pro checkups, how to get community apps to the same service etc. etc. etc.

And after the move, it would be nice to have more than two apps to translate - like, community apps too

1 Like

Tracking update:

  • terminal keyboard is coming along nicely
  • keyboard layouts still need people from almost all languages to define what are their preferred character layouts (vertical and wide layouts - maybe terminal too?)
  • translation server change is still in the works, it seems [edit to add: Zanata is down]
  • translations updated and all languages need to update, but depending on the server change, volunteers should make sure that the change is not happening while they work or risk losing latest updates
  • I’ll update the table once the server change is done

I’m working in the Spanish wide layout, it’s a bit tricky because when I switch to landscape the system is unusable, once is ready I’ll upload it to the git repository.

@dcz It’s possible to use the Del key? I’m thinking that it would be be useful to have it when you press shift and then backspace to remove the next character, because sometimes when you want to remove a typo in a touch screen you press in the wrong place and it’s a bit difficult to move the cursor where you need it.

Sooo… I started to write this several times over past some weeks but stuff happened and now it’s end of July. When the change happened, I didn’t have time to jump right in and now I’m playing catch up. My initial text went a bit long, so here is the portion similar to that what I’ve tried to do previously – to track what’s going on with the translations.

Current situation: stats and overview

So, the translations have mostly ground to a halt, it seems. When Zanata service became unreliable and the whole management of those language files was moved to Damned Lies (DL, Ironically, yesterday when I was preparing this, I noticed that it was having bad times, but that was resolved in a couple of hours.

Now, I’d like to point out that the move effectively gave a new home to managing the translation files but at the same time it took away the tools to translate – a necessary move if you’re looking at this from coder’s perspective but a big step backwards if you are only doing translations. From what I’ve been able to find out in my limited searches (✓&state=merged&search=translation), only few active people have known a way to push their translation updates onward in the process. This was probably because they’re familiar with how development and git work. For the rest of us, there are plenty of guides and help at DL for the general stuff and from Gnome dev perspective. But they do not cover everything and the breadcrumbs/explanation/path from L5 forums to to translations to merge (the final step to actually include the translation into the app) is missing. With some of that I’ll try to help out in a separate posting in a day or two. There’s a lot more to say there and I want to keep that separate from this stats and situation overview.

Returning to the point, the change happened and I’d have to say some follow-through is still waited on. Many languages are where they were left at Zanata, several months ago. But it’s not all bad. There has been work done by active individuals: Romanian, Ukrainian, Catalan and Danish have to be mentioned – keep up the good work. A couple of others have tried to be activate too, but have not been directed towards being considered to be merged yet, it seems.

As a new thing to most, please notice a new app to translate. In addition to phosh and chatty/chatts , we now have calls in DL. At some point, if memory serves, at least keyboard and documentation should also be expected to appear for translation, and likely some other apps too.

The excellent thing about DL is, that it has good public statistics on how much translation has been done – both relative percentages and absolute numbers of strings. So, no more manually collected tables here. I did gather a bit of an overview of them, though, as well as Pure Maps (which is on and not DL).


  • strings: 180 (538 words)
  • languages started: 21 languages/locales, of them 6 are active and fully (over 95%) translated
  • notes: more languages should start this but translation levels are pretty good
  • last update: couldn’t tell you at the moment, as they’ve not been announced (maybe a few months back?)


  • strings: 44 (100 words)
  • languages started: 36 languages/locales, of them 7 are active and fully (over 95%) translated
  • notes: mpst languages are unchanged and getting worse, as more strings have been added/updated
  • last update: couldn’t tell you at the moment, as they’ve not been announced (maybe a few months back?)


  • strings: 40 (104 words)
  • languages started: 13 languages/locales, of them 6 are active and fully (over 95%) translated
  • notes: more languages should start this but translation levels are pretty good of those that have started
  • last update: couldn’t tell you at the moment, as they’ve not been announced (maybe a few months back?)
  • [edit to add] for reference, it takes about 45 minutes to do the translation file (slow-ish pace)

pure maps:

  • strings: 469 (1921 words)
  • languages: 23 languages/locales started, of them 10 are active and fully (over 95%) translated
  • notes: for more, there is also the related OSM Scout server that can be used to have your own map services (483 strings, 3976 words, 11 of 13 languages seem active and more would be welcome)
  • last update: a couple of months ago (server seems steady, rarely updates)
  • [edit: adding @rinigus here - maybe could get some comment from app developers perspective on translations and translating etc.]

Should there be some other app somewhere that should be kept on eye on (we’ll see how much effort tracking those needs)? Preferably something that’s going to be central to L5 experience. The ones that I previously had listed:

Librem 5 related translations combined tracking (all Purism L5 apps, now called “release set”) can be seen in It seems a bit “harsh” as a meter, as it calculates all apps and percentages equally – good activity in some doesn’t mean much if another app is neglected. All in all, there are 37 different locales (counting all languages and their separate regional codes) that have started work on one L5 app or another.

I won’t include the virtual keyboard layout situation here (maybe @dcz could comment on that), but just as a reminder, localization of keyboard layouts needs native users to define what is their preferred layout (see:

At the forum (Where is the most interest in Linux phones?), @amosbatto did (again) a longer forum article on where the L5 had been searched and in which countries there was indication of interest towards it. This is valuable for internationalization efforts, as it tells (a) which languages are the ones that should be translated, and (b) which language areas need more hype and translations for them to get interested – it works both ways.

And if you are interested in the shortcomings of, and fixes to, Damned Lies, just this coming Monday evening (27.7.) there is an online seminar ( at GUADEC 2020 (Gnome’s biggest yearly conference). I’m not sure if I can make it, so if someone here does, it would be nice to see a couple of notes.

I’ll try see if I can edit a readable text about how to do L5 work with DL, and the differences to previous, to help anyone interested to continue the work.

1 Like

I can’t figure out how to submit the PO translations files for Spanish. I tried submitting the files as attachments at, and, but it doesn’t seem to work.

Any ideas?

Absolutely. The process is broken, the chain is cut, so to speak. The DL system is made for Gnome and Gnome app development, where (as far as I understand what’s happening under the hood) the uploaded .po is automatically committed and forwarded for merge. That is what you are trying to do and it’s correct. But L5 app development apparently isn’t using the same process because Purism naturally has it’s own independent system. At the moment, the few translation updates I’ve seen merged, where when an individual has been involved with L5 git and offered the .po there for merge. That manual way is not very practical (but it may also be the only way as I’m not familiar how much the process can be automated - this is not one sided as the DL system is also a bit… in need of development) and having individuals ferry the files kinda defeats the purpose of translation file management. [edit to add: in my language, the phosh file has been locked waiting to be merged (or something) since spring and there is no functionality to do anything to it, even by translation group seniors]

When the change happened, there was probably so much going on that the finer points (or the translator perspective) weren’t tested and documentation is lacking. I’ve asked clarification to do these final steps correctly and efficiently as I have no idea how they should work (only what I can see from the outside - and adding to this: maybe the DL to L5 apps process works but it’s just not showing). This was also what I was hinting at with the additional text coming soonish, as I don’t want to rush with any advice that may change. And since it’s weekend, I guess we’ll have to give it few days.

Chipping in as a developer. On Sailfish, the OS where Pure Maps and OSM Scout Server started, many of us use Transifex. Warning, it is free as a beer, their infrastructure codes are not open source. Service is free for open source projects. For closed source codes, you have to pay. With this warning given, let me describe the usage.

Pure Maps and OSM Scout Server use different translation approaches. While Pure Maps is using POs, the server is using Qt-based translations. As far as I know, Transifex supports other approaches as well .

In general, use of this service is easy. This is both for the developers and translators. Such ease of use is the main attraction and allows us to work efficiently.

On developer side, you register yourself and then your projects. As I do it rarely, I don’t remember the details. But they have nice docs describing what to do. As far as I can see, Pure Maps config is in . My translation related work is the first half of . As you could see, all simple and I don’t do much more in addition. Once in a while, I get an email to approve the new language request for the project. As soon as I approve, translators are automatically accepted into the project and can work on them without me. All I have to do it to pull their work.

On translator side, it should be easy. However, I don’t have first hand experience with it. As far as I can see, translators are given strings via online form and they just fill it. It is possible to also approve translations.

I would say that I am happy with this service and would use it for other projects as well. As I can pull all the translations into Github repo, I don’t personally care whether they have been in the “locked” database behind closed-source components in between. As simplicity and efficiency is there, I consider the time used by developers and translators as a major asset that needs to be used as well as possible.


I’m interested in how much and in what way you have had to help translators with contextual information and additional information. I remember when doing the PM translations that the strings were pretty simple and there didn’t seem to be that many terms with multiple meanings but was this always the case? I mean, PM has been in the works for some time already then and there was already half translated (inactive) language there, so were any changes needed? Were there ever problems with translations or feedback related to it that needed a bit of problem solving? Have you ever done any quality control or tried machine translations (google or others)? What’s you take on the few languages that have started but never gotten very far - have you tried getting people to participate?

Let me try to reply to all these questions:

My general attitude applied to Pure Maps and OSM Scout Server translations has always been that it is a part of the project where developer does not have to intervene much. It is something that users are doing for users. All what I have to do is to provide means and answer or correct in the code when needed.

I remember when doing the PM translations that the strings were pretty simple and there didn’t seem to be that many terms with multiple meanings but was this always the case?

There could have been strings that needed some change, either in PM or the server. In these cases, you get the feedback via github, forums, or Transifex. Make the change in the code and upload new strings. All as expected, I think

I mean, PM has been in the works for some time already then and there was already half translated (inactive) language there, so were any changes needed?

I take half-translated languages easy. If they are not ready then they don’t get pulled into the source. It shows that there is insufficient demand in that language and it is mainly kept for new translators.

Were there ever problems with translations or feedback related to it that needed a bit of problem solving?

As mentioned, maybe few strings had errors in English or were not clear. Then those got fixed.

Have you ever done any quality control or tried machine translations (google or others)?

No, never done that. The control is via users as far as I understand. Some discussion was prompted by Spanish translation of one of the projects. But this discussion was between users and it was not something I could contribute to anyway. In the end, one of the users prevailed and that was that.

What’s you take on the few languages that have started but never gotten very far - have you tried getting people to participate?

No. If language is dropped, I consider that it is either not needed or it does not have someone among the users who takes the initiative to finish it. As these projects are large and I have also few other things I am doing, there is no time nor desire to start hunting for translators. Again, it is something that users are doing for users and it is what you could do without programming knowledge.