998 replies to this topic

[Taapat]

And where is the problem with the search?

Why can not you use mapping from locales, why do you need your own mapping?

[IanSav]

Hi Ims,

 

It appears that "ES 202 130 - ETSI" also seems to define how language is to be presented.

 

These are massive documents so give me some time to scan them and I will follow the directions they prescribe.

 

Regards,

Ian.

[IanSav]

Hi Taapat,
 

And where is the problem with the search?

Before my code change only English characters were allowed for the search.

Why can not you use mapping from locales, why do you need your own mapping?

I do now use mappings from the locale based languages. That is the code I wrote! It wasn't there before.
 
Regards,
Ian.

[IanSav]

Hi,

I have had a request to remove the accented characters from the "en_GB" keymap.  Those accented characters are documented but apparently not used.

 

Does anyone have any objections if I remove the five accented characters from the en_GB locale?

 

Regards,

Ian.

[ims]

Here is "Standardization Supporting Cultural Diversity: Character Repertoires ..."

[Taapat]

I do now use mappings from the locale based languages. That is the code I wrote! It wasn't there before.

So where is the problem of using different layouts for different languages in serach?
Why do you need to use the same layout for all languages?

Back to the Latvian layout.
I am convinced that it is best to use the alphabet method. Such has been used in Latvian for many years.
I see that in EU 202 130 is defined differently. Similar to the ims offer.
Ok, if there is a standard, need to use it and need to change according to the standard, but not how it has changed now.

But for example, if you look at the Russian layout in this standard, you see that the national symbols are the first.
Therefore, each language needs or to be changed according to the standard, or leave it was before.
But do not implement layouts created by mechanical principles do not understanding anything in this language.

[IanSav]

Hi Taapat,

 

Can you please settle down.  You are going to burst a blood vessel if you keep up this aggravation.  Being rude and pushy isn't helping your cause.

 

Ims provided the authoritative information about 03:00 in the morning my time.  (You do realise that I am in a completely different time zone?)  I stay up to the very early hours of the morning to try and offer overlap time with the many European developers with whom I work.  I haven't even had a chance to study the documentation least not adjust the code to match its directions.

 

As time permits I will code the changes.  I hope to have some time later today (Australian time).

 

Regards,

Ian.

[zeros]

A space could be in first place on SMS Type keyboard and number 1 on the second? Just a suggestion from me (as also mentioned by ims)

Attached Files

•  D6FC837E-F334-4A1A-A7F0-14C02D72B61B.jpeg   88.7KB   2 downloads

[littlesat]

Indeed might be a good suggestion....

[Taapat]

@IanSav when I ask you to change it immediately?

If you answer in this way I ignore the fact, that you do not know how to work with git and I make changes myself.

Edited by Taapat, 6 September 2018 - 06:29.

[IanSav]

Hi Zeros, Littlesat & Ims,

 

A space could be in first place on SMS Type keyboard and number 1 on the second? Just a suggestion from me (as also mentioned by ims)

 

The reason I would like to keep the SPACE as the second element in the "1" list is that it is more visible on the screen in that position than it is as the first character.  There are few remote controls that document the SPACE character.  I happen to have a few here (they are common on the Beyonwiz hardware available in Australia) so I would like to keep the layout is sync with the remote controls that do show the SPACE.

 

 NumberPad.jpg   75.82KB   1 downloads

 

I have presented why I would like SPACE to stay as the second character.  I checked the reference documentation supplied by Ims but I didn't find any suggested locations for SPACE.  ("The need for language-specific repertoires for non-letter characters is not addressed by the present document.")  If you all prefer it to revert to the first character then I will accept the vote of the majority.

 

Regards,

Ian.

 

[IanSav]

Hi Taapat,
 

@IanSav when I ask you to change it immediately?

 

The tone and language used in your posts to me imply that you are annoyed with me.  The words used appear to me that you want me do everything your way and you want those things done immediately.

 

If you answer in this way I ignore the fact, that you do not know how to work with git and I make changes myself.

 

I have repeatedly ask you to be polite and respectful but you still post what I consider to be harsh posts.

 

I have no idea why you keep asking me if I know GIT.  The question has been asked and answered.  My answer has been supported by other developers with whom I work.

 

Please don't threaten me with forced code changes.  The master copy of the code is not in the OpenPLi repository.  If changes are made that conflict with the design, functionality or compatibility of the other repositories then changes will be reverted or overwritten.

 

All the other users and developers here have engaged me in discussions and advocated for the changes they want.  No threats were required.  I respond well to discussions and logic.  I am always happy to discuss my code and will always listen to requests for changes and/or improvements.  I won't promise to change everything but I will always respect and listen to the thoughts of others.  You should note that there have been many changes made to my code after polite and friendly discussion.

 

Regards,

Ian.

[Pr2]

Check here:

 

https://github.com/E.../images/remotes

 

You will have an overview of the different possible RCU and you will see that many use the 0 key for space.

So having it on 1 is not as universal as you think, it is rather the STB manufacturer by INI that use 1 for space, most of the other one use 0 (some do not display anything about space).

 

May be foreseen space on 0 as 1st char

 

Pr2

Edited by Pr2, 6 September 2018 - 10:47.

[zeros]

There's no concern for me then. Anyway, Google says "0" works as space, I also find that.

[Rob van der Does]

The reason I would like to keep the SPACE as the second element in the "1" list is that it is more visible on the screen in that position than it is as the first character.  There are few remote controls that document the SPACE character.  I happen to have a few here (they are common on the Beyonwiz hardware available in Australia) so I would like to keep the layout is sync with the remote controls that do show the SPACE.

I fully second that. Even then the SPACE is difficult to distinguish.

[IanSav]

Hi Guys,

 

I can't find any authoritative opinion on where the SPACE should be.  It appears that I am the only one with a SPACE indicated on the remote control.  I just checked my old Sony Ericsson T68i phone and it also has the SPACE after the 1 on the "1" button.  I would like to keep the SPACE after the "1" where it is now but I will bow to a consensus of public opinion.

 

So, where do people want the SPACE?  Stay on "1", move to "0".  Can the SPACE stay as the second character?

 

Regards,

Ian.

[zeros]

In my terms, you can stay as you currently have, the reasons are clear.(The arguments that you said are convincing)

[IanSav]

Hi Ims,

 

Can you please test this revised version of NumericalTextInput.py to see if the changes to Czech are correct.  Interestingly enough the old data in the repository was incomplete.  The guide link you provided showed that some characters were missing.  That document has been VERY helpful.

 

There is one thing I would like to check.  In the document the position of the upper case characters is not documented.  In this test version I put the digits immediately after the lowercase English letters as you suggested.  To me it looks unbalanced and wrong.  I really do think that the digit would be better as a separator between the lowercase and uppercase letters.

 

Can you please look at the code attached to this post and confirm if I should keep the original version I committed to the repository or switch to this version.  In any case I will go through all the languages and correct them to add any missing characters as per the specification document.

 

Regards,

Ian.

 

Attached Files

•  NumericalTextInput.py   10.48KB   2 downloads

[Rob van der Does]

I really do think that the digit would be better as a separator between the lowercase and uppercase letters.

Exactly!
+1

[ims]

 

I really do think that the digit would be better as a separator between the lowercase and uppercase letters.

Exactly!
+1

 

@Ian: I will try it evening ...

 

Why use numbers as separator between the lowercase and uppercase letters??? Numbers must be 3rd (4th) char as is used on phones.

May be, "1" and "0" are different.

 

Will you write on this keyboard in UK or Aus or we in Czech ?