Translations and virtual touch keyboards - tracking localization

Hardware Librem 5
26

You can place the m in the second row, I did it for the spanish layout with the ñ character

keyboards.png720×420 84 KB

3 Likes
27

@uzanto How about it, could you take this further now and submit? :smiley:
(About 76 million native speakers and about 235 million daily, fluent speakers and maybe another 77 to 110 million secondary speakers would thank you :slight_smile: )

1 Like
28

I’ll do it tomorrow, it’s just place the m next to the l and send the request to purism gitlab?
@leo-numethik what’s the most common special character do you use in french? because it can be placed in the main view next to the n, maybe ç Ç?

1 Like
29

Thanks. You are the expert of us. I’m a bit in the dark what is needed and only assume that the placement change (length of line / number of characters per line) needs to be updated/edited somewhere. This layout was a mockup based on it.yaml.

30

Yes, Çç would be very relevant. The possibility of a combo with the ^ would be really cool too, maybe in the accents panel?

31

So, updated. But I could not produce Ç+^ or ç+^ (is that even possible, only found Ḉḉ) - did I misunderstand or can you put it here for copy paste?

views:
    base:
        - "a z e r t y u i o p"
        - "q s d f g h j k l m"
        - "Shift_L   w x c v b n ç   BackSpace"
        - "show_numbers show_eschars preferences         space        , period Return"
    upper:
        - "A Z E R T Y U I O P"
        - "Q S D F G H J K L M"
        - "Shift_L   W X C V B N Ç  BackSpace"
        - "show_numbers show_eschars preferences         space        ? period Return"
    numbers:
        - "1 2 3 4 5 6 7 8 9 0"
        - "@ # € % & - _ + ( )"
        - "show_symbols   , \" ' colon ; ! ?  BackSpace"
        - "show_letters show_eschars preferences         space        ? period Return"
    symbols:
        - "~ ` | · √ π τ ÷ × ¶"
        - "© ® £ $ ¥ ^ ° * { }"
        - "show_numbers   \\ / < > = [ ]  BackSpace"
        - "show_letters show_eschars preferences         space        ? period Return"
    eschars:
        - "â Â à À æ Æ ä î Î ï"
        - "ê Ê è È œ Œ ë é É ö"
        - "show_numbers   ' ÿ ù û ü ô Ô  BackSpace"
        - "show_letters show_eschars preferences         space        « » Return"
32

No ahah. I was talking about the âÂ, êÊ, îÎ and so on, as I didn’t see it on the @uzanto’s screenshots.^^

Your last proposition is the best that we can achieve for now in my opinion.

EDIT: actually, the çÇ is not useful anymore in the fifth panel in my opinion. But it’s also a thing of habits. Maybe another french speaker could tell us if it makes sense for him.

33

I edited it again [to the last version above] and removed çÇ from the eschar view because they were already used. Also, because I had miscalculated (one too many characters in that row), and replaced with " ’ ". It’s a double as well, but might speed up writing when you don’t have to search for it from another view… or would some other character be even more useful (this may go to the area of “over optimization” at this point - can be changed later depending on feedback)?

34

@JR-Fi: Thank you very much for this overview!

One of the things we will be missing very soon is some kind of “best practices”. ATM we can take a look at the other layouts to learn how to make a good layout, but as things get more fragmented (with more layouts), it’s getting harder to find the “best” way to create a layout and have a consistent UX over different layouts (of similar kind).

For the German layout, it was quite easy as it doesn’t need a lot of special characters. I just had to take an existing layout and modify it a little bit. But even in this simple case I had to decide if I wanted to keep the German umlauts in a special layer (with “äÄ” as the switch key) or put them on the main layout. I decided to keep them in a special layer to avoid cluttering the basic view and avoid shrinking the button size. But that was just my personal opinion! It’s probably neither good nor bad - just a thing of personal preference.

Some small points I noticed as I made the German layout (and that should be consistent over all layouts IMO):

  • Do we want the switch key between numbers and letters to be upper case letters “ABC” as in the original US layout or lower case letters “abc” as we have it in some layouts now?
  • The preferences key (globe symbol) should probably be consistent over layouts and use the “special” outline
  • The view/button named “eschars” comes from the Spanish layout. For German I renamed it to “dechars”, but maybe we want a more generic name there? What about “accchars” for accented characters?

Are there other things I missed?

My general understanding of the key color in the layouts is this: All keys that produce a normal character/letter output are “light grey” and other special keys as the “settings” key, “bachspace” key and keys that switch to another layers like “ABC”/“123” are “dark grey”. I hope that this inference I made is correct.

The only very different layout at the moment is the Japanese Kana layout. I tried to add some comments in the YAML file to document some of the special things done there - hope that helps a bit.

What do you think? Discussion welcome… :slight_smile:

1 Like
35

Excellent points. They may not seem relevant to individual user or at the moment but later one they might start to irk, so it’s good to get them settled now. I’m happy with your points being here and agree with them, but I think a copy should also be submitted to somewhere in git and/or dev mailing list, maybe(?).

(and btw. I thought “eschars” was from extra or especial characters… :wink: )

1 Like
36

Good idea - but let’s wait a bit until we have some more comments in this thread and can make a list of initial “best practices”. @dcz: What do you think about a “best practice” document in the git repos?

Interesting… that’s an example of how different people interpret the same code in different ways… then I’ll take a note to correct this in the next MR for the German layout. Your interpretation seems reasonable :wink:

1 Like
37

Best practices would be useful, and I started an issue on the documentation repository: https://source.puri.sm/Librem5/developer.puri.sm/issues/143 for the general idea of keyboard docs.

What I think would be even more useful than best practices is a basic introduction and format description. As I’m putting all my effort to pack new features in, and you guys have figured it out already, it would be extremely cool to have such a document.

If anyone is already working on best practices, tutorials or whatever, please make a MR in the keyboard repo. If we later decide to use the main docs, we can move the files there.

38

I took a look at Zanata just now: someone has translated phosh to latin :nerd_face: :+1: :amphora: :classical_building:
… now that’s old school :sunglasses:

(I’ll update the table again this evening)

1 Like
39

eschars was for ‘especial’ and I did the change from ABC to abc because you are going to lower case when you press there really.

I think it’s a good idea to do the best practices entry and then everybody can suggest any change in there.

1 Like
40

Thanks for making that clear - then it’s OK for most layouts and I will patch mine (back to “eschars”) to be in line with the rest :sweat_smile:

With your explanation, I vote for the lower case version “abc”, too :+1::smile:

41

For me it’s ok like this.

42

I’ve started using it as a way to take breaks from other work. :slight_smile: I’m working on Chatty now.

It’s been years since I studied Latin, and I’m by no means an expert, so if any of the translations seem incorrect, I’m open to feedback.

1 Like
43

I’ll try to pound out Pure Maps Japanese translation this weekend. Note that Japanese is mispelt in the screenshot for ‘Languages’ col (Japanise)

1 Like
44

Corrected and updated: Turkish among others previously added. Next update to the table during the weekend, maybe.

45

Merge request for fr.yaml done

2 Likes