998 replies to this topic

[IanSav]

Hi,

 

I have the new code and documentation ready to go, I am just waiting for instructions from Blzr to confirm that the Polish Programmer's layout is the one to associate with the "pl_PL" locale by default.

 

Are there any other corrections required?  I really want to move on to other projects.

 

Regards,

Ian.

[blzr]

Hi IanSav,

 

The programmers layout is virtually sole one used in Poland, according to my best knowledge, so it definitely needs to be default for pl_PL...

As to QWERTZ layout, I'm not sure, it's rather a remnant of the times of typewriters here, I personally never saw it anywhere used in computing nowadays (but don't know, if it's already made, maybe you can leave it as an alternative one, just in case... (?))

 

 

[IanSav]

Hi Blzr,

 

Thank you for the confirmation.  I will commit the code with the Programmer's version as the default for Polish but will leave the alternative available should it be helpful for anyone to use.

 

Regards,

Ian.

[IanSav]

Hi,

 

Updates submitted to the repositories.

 

Regards,

Ian.

[ims]

Hi Ian,

 

you should prepare greenLabel texts (line 54) for gettext, because when are generated .po files, are in python accepted _(".......") strins only => 'Search' will not be added to .po file => will never translated. I know, that you translating it as _(greenLabel), but when missing word in .po, there will be still original only.

 

f.eg.

VKB_SEARCH_ICON: ("Search", u"ENTERICON"),

should be

VKB_SEARCH_ICON: (_("Search"), u"ENTERICON"),

[IanSav]

Hi Ims,

 

you should prepare greenLabel texts (line 54) for gettext, because when are generated .po files, are in python accepted _(".......") strins only => 'Search' will not be added to .po file => will never translated. I know, that you translating it as _(greenLabel), but when missing word in .po, there will be still original only.

 

f.eg.

VKB_SEARCH_ICON: ("Search", u"ENTERICON"),

should be

VKB_SEARCH_ICON: (_("Search"), u"ENTERICON"),

 

All the GREEN button and keypad associate buttons are already translated in a way that triggers translation text harvesting.

 

The five key words for the GREEN button and associated keypad grid ("Done", "Enter", "OK", "Save" and "Search") get specifically translated on lines 60 through 64.  These translations prime the translation database.

 

All the words in the first item of the dictionary tuple are translated on line 516 as you noted.  The translation strings are already in the database by virtue of the previous translation of the identical strings as described in the previous paragraph.

 

Is there something I have missed?

 

Regards,

Ian.

[ims]

Ok, I overlooked last patch...

[IanSav]

Hi Ims,

 

 

Regards,

Ian.

[ims]

 

2. Where I can see DELETE button requests by a user?

Or do you lie about it, just like before, why anyone can't change the code?

 

 

Place Delete to right was my request, because is very easy, when you need toggle between Backspace and Delete with Up/Dn keyboard only. Before it was Delete in bottom line, but cca 3-4th char from right

[littlesat]

Place Delete to right was my request, because is very easy, when you need toggle between Backspace and Delete with Up/Dn keyboard only. Before it was Delete in bottom line, but cca 3-4th char from right

 

Good suggestion... but is the issue only for the delete button?

We can also suggest IanSav first completes it and as soon it is stable we make some "PLi" finetuning...
 

Edited by littlesat, 10 April 2019 - 12:03.

[WanWizard]

The root cause of all this misery is the design and architecture of Enigma2. Global variables, global method, tight coupling between seemingly unrelated function, it is a disaster waiting to happen (no, that happens time and time again, like here). A change in some bit of code may NEVER create an issue in another bit of code.

 

We will keep running around in circles until we (I use the collective we, as in all Enigma2 developers) sit down together, leave our ego's at home, and design and build something better.

[littlesat]

The biggest issue regarding improve e2 are plugins loved by users... when you improve a part plugins will (not even may) fall.... there are tons of stuff that does shout for revision, improvement and even complete rewriting...

My 2 cents.. better go for stuff that adds real value...

Regarding the setup screens I think use green for safe and red+exit for close and never Ok for save... and never show press ok for save... I suggest these are ‘just’ some custom screens that need revision.... and when you have eg fastscan add a yellow button to start fastscan (and let ok also respond on it to be backwards compatible)

[WanWizard]

They only way to solve that, is either stop developing, or redesign. Any other way forward will only make the problems bigger....

[IanSav]

Hi,

 

Are there any Ukranian speakers here?

 

Regards,

Ian.

[IanSav]

Hi,

 

Can I please have an opinion on which of these T9 layouts is correct for Ukrainian?  (Look at the character entry table on the bottom left of the screen.)

 

Previous layout:

 Ukrainian-Prev.jpg   171.18KB   0 downloads

 

New layout:

 Ukrainian-New.jpg   169.47KB   0 downloads

 

Regards,

Ian.

 

[-M-]

It's depend what you want it to be. The first seems to be English+Russian+Ukrainian, the second English+Ukrainian.

 

PS. Many people in Ukraine speak Russian as main language.

[IanSav]

Hi -M-,

 

I was told by a Ukrainian OpenATV user that the previous layout was incorrect / inappropriate.  I was told that I should be using the new layout.  As I am only an English speaker I wanted to get a second opinion from this group.  If I adopted the new layout for all images would this create a problem?

 

Regards,

Ian.

[-M-]

In short: I think Ukrainian should be Ukrainian.

Because Ukraine have their official language and the software should adapt to this. This is also for respect/polite. In some part of Ukraine they speak Ukrainian. Not only that, you shouldn't speak Russian in some parts. You aren't welcome if speak Russian. So Ukrainians normally speaking Russian, needs to speak Ukriane while visit these parts. I will guesss that to have Russian characters in the software for Ukraine language can be seen as negative/disrespectful.
However I understand that some Ukraine people would like to be able to write in both language. Can for example be useful at EPG search (or might it be an automatic understanding/translation between some characters of the two languages - would be nice, even for other languages, e.g. Scandinavian).

PS. I haven't checked that all T9 characters are correct.

[IanSav]

Hi -M-,

 

Thank you for your advice and assistance.  I have made the Ukrainian only keyboard layout the default.  Those that want the Russian characters can select the alternate layout.  That is, both versions are now available.

 

I would welcome your review and advice on the T9 characters as well.

 

Regards,

Ian.

[IanSav]

Hi -M- or anyone who knows Ukrainian,

 

There have been further comments regarding character issues in the Ukrainian layout in the NumericalTextInput  pop up screen.  This is my current proposal for the corrected Ukrainian layout::

 Sample.jpg   66.29KB   0 downloads

 

Can I please have a comment if this an acceptable layout / correction?  If there are problems please give me specific corrections.

 

(NOTE: I mean no offence if I have made any mistakes.  I only know English and am using Google to try and manage the other languages in my code.)

 

Regards,

Ian.