Jump to content


Photo

Language assistance requested...


  • Please log in to reply
998 replies to this topic

Re: Language assistance requested... #581 Pr2

  • PLi® Contributor
  • 6,165 posts

+261
Excellent

Posted 31 August 2018 - 15:45

If you want to know what happens during build you can check my script:

 

https://github.com/O.../updateallpo.sh

 

It does exactly what is performed during building the po and pot files.

For the xml file the build process or my script is calling this python file:

https://github.com/O...op/po/xml2po.py

 

If you have some doubt, before building you need to use:

 

./configure --with-po

 

Then start the normal build process.


NO SUPPORT by PM, it is a forum make your question public so everybody can benefit from the question/answer.
If you think that my answer helps you, you can press the up arrow in bottom right of the answer.

Wanna help with OpenPLi Translation? Please read our Wiki Information for translators

Sat: Hotbird 13.0E, Astra 19.2E, Eutelsat5A 5.0W
VU+ Solo 4K: 2*DVB-S2 + 2*DVB-C/T/T2 (used in DVB-C) & Duo 4K: 2*DVB-S2X + DVB-C (FBC)

AB-Com: PULSe 4K 1*DVB-S2X (+ DVB-C/T/T2)
Edision OS Mio 4K: 1*DVB-S2X + 1*DVB-C/T/T2
 


Re: Language assistance requested... #582 Huevos

  • PLi® Contributor
  • 4,621 posts

+161
Excellent

Posted 31 August 2018 - 16:15

@PR2, what I am trying to explain is that the string for translation comes from the repo being built. I doesn't come from other repos. If it did it would be a hack.



Re: Language assistance requested... #583 IanSav

  • PLi® Contributor
  • 1,491 posts

+51
Good

Posted 31 August 2018 - 16:17

Hi Littlesat,
 

On all other locations the color parcing is done in hex... so I don’t understand that issue...


I think I am pushing the boundaries of what the parameters were originally coded to do.  The code in skin.py specifically expects the parameters to only be of type int or float!  In reality I would like to use the skin based "#" colour codes or even better the colour names.  The parameter code should be expanded to accept all data types.  The data should then be available to the code that looks for the parameter to interpret and process the data provided by the skin.

 

Indeed it would be helpfull taapat gives us an example of the plugin cullpit... but still renaming stuff in e2 is always at risk. Even when the names are not fully right you have to do it with care...

Had Taapat talked to me about what he is doing then I could have offered a simple solution.  Rather than his hacking through my code with a huge sledgehammer, and breaking other systems, I could have used a fine scalpel and simply added:

	def okClicked(self):  # Deprecated legacy interface to new processSelect used by YouTubeVirtualKeyBoard
		self.processSelect()

The other point I am trying to make is that groping into VirtualKeyBoard in this unorthodox way is not doing what I think Taapat expects.  In VirtualKeyBoard if the user enters "BCD <PREV> A <NEXT> <BACKSPACE> then the user will see "ABC" but YouTubeVirtualKeyBoard will see "BCDA".  Is that really what is wanted?

 

Again talking to me rather that being confrontational could have had a simple fix and a potential plugin issue could be investigated.  By the way, I believe that NumericalTextInput may be a better way to capture characters being entered by the use in real time.

 

Regards,

Ian.



Re: Language assistance requested... #584 IanSav

  • PLi® Contributor
  • 1,491 posts

+51
Good

Posted 31 August 2018 - 16:37

Hi Taapat,
 

@IanSav I have never asked to do anything for me.
I am asking follow changes in sources.


No, but I did offer to help and you and investigate the problem but you ignored me.
 

But your problem is that you do not offer changes.


Rubbish, the corrections to the Polish keymap were done by someone else and fully accepted by me. They submitted the change and explained exactly what they did and why. They simply corrected a mistake and made no changes that broke other things.  Your changes broke things.
 

You offer your files instead of changes, which revert all other changes.


Yes, if those changes are ill considered and break other things they will be reverted. This can happens in any repository at any time.  If the commit notes provided accurate information of exactly what was broken and why them much of what followed could have been avoided.  Similarly adding me as a reviewer when changing code I recently wrote and am still tweaking to address teething problems would have helped alert me to problems.  Discussing the problems here would have also resulted in the fixes you wanted.  You chose to not talk to me an any productive way.  That is not my fault.
 

I feel that you have problems using git, so I already asked if you have heard about "git cola".


I am no GIT expert but I have no problems with day to day GIT usage. However OpenPLi is NOT the master repository for my work. I make pull requests here because, to my knowledge, no-one from OpenPLi ever fetches code from other repositories.

 

You need to remember that I actively code for three images.  I am trying to offer compatible improvements to all those images without creating merge problems between them.  It is not easy.  Poorly considered and ill conceived changes only make the job even more difficult.

 

Regards,

Ian.



Re: Language assistance requested... #585 Taapat

  • PLi® Core member
  • 2,345 posts

+121
Excellent

Posted 31 August 2018 - 16:52

If you used a cherry pick then there would be no problem.
But I see that git is a problem for you.
You change the files and it is wrong if you maintain multiple imiages.
I see that others have also paid attention to your mistakes: https://github.com/O...65f81d863560dac
I hope that it will change your habits.


Re: Language assistance requested... #586 IanSav

  • PLi® Contributor
  • 1,491 posts

+51
Good

Posted 31 August 2018 - 17:30

Hi Taapat,

 

If you used a cherry pick then there would be no problem.

But I see that git is a problem for you.
You change the files and it is wrong if you maintain multiple imiages.
I see that others have also paid attention to your mistakes: https://github.com/O...65f81d863560dac
I hope that it will change your habits.

 

Please read what I write and not reply to things I didn't say.

 

I am interested that you think that everything I do is a mistake.  Am I doing anything right?  Don't bother answering.  I know what you will say.  "No!"

 

What a shame that many of my changes fix things and actually make Enigma2 much better for users.  I guess that is a mistake too.

 

I am happy to change habits when there is a justifiable reason to do so.  Will you be changing any of your bad habits?

 

Regards,

Ian.


Edited by IanSav, 31 August 2018 - 17:30.


Re: Language assistance requested... #587 WanWizard

  • PLi® Core member
  • 70,220 posts

+1,798
Excellent

Posted 31 August 2018 - 17:48

The point I think Taapat is referring to is that you copy entire files, instead of working with diffs. This means that any change the image devs themselfs make in the file are deleted the next time you copy an update in from your local system.

 

You can only do that if you (and you only) are in full control of the file, which is this case you are not.

 

What Taapat is hinting at, and what I think must happen, is host the upstream of this in a separate repo (where you do have full control), and from which the different images can either build (if they don't want or have own changes/additions) or pull (if they do).


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: Language assistance requested... #588 Huevos

  • PLi® Contributor
  • 4,621 posts

+161
Excellent

Posted 1 September 2018 - 01:24

The point I think Taapat is referring to is that you copy entire files, instead of working with diffs. This means that any change the image devs themselfs make in the file are deleted the next time you copy an update in from your local system.

No I don't think so. Ian regularly sends us PRs and they are always against the latest copy. He obviously sent those revert changes because he doesn't agree with them.

 

It is PLi's repo so they can do what they like but it is very frustrating for a developer doing a major reform on some code and someone else comes along and starts breaking it before the reform is even complete. From Taapat's changes it is clear that he doesn't understand how Ian's code works.



Re: Language assistance requested... #589 littlesat

  • PLi® Core member
  • 57,062 posts

+698
Excellent

Posted 1 September 2018 - 07:43

Why making the shift colors configurable by the skin in the first place? Making too much configurable is asking for complications...

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Language assistance requested... #590 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 1 September 2018 - 08:08

I don't agree. Making everything configurable (and having it working too) is a sign of good code design. It doesn't that Joe Average needs to see all the options.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: Language assistance requested... #591 littlesat

  • PLi® Core member
  • 57,062 posts

+698
Excellent

Posted 1 September 2018 - 09:17

Not agree... a good design does not need tons of customs tweaking possibilities. In addition every thing that can be adapted makes it more complicated to get to a good code design... for a good code design you first need to set a proper scope.

In this case when changing these colors is in scope it should be in hex and not decimal.

when a skin can change the color it does not help at all... eg someone reports here the green button does not work, while with an other skin it is blue... might this feature make support more complicated? so should it be in scope in the first place? When it is just intended to get the colors in the skin style and basically they are the same I agree it should be in scope, but when it is intended to change green to blue or so then not

Edited by littlesat, 1 September 2018 - 09:23.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Language assistance requested... #592 IanSav

  • PLi® Contributor
  • 1,491 posts

+51
Good

Posted 1 September 2018 - 11:02

Hi Littlesat,

 

The text font colour in VirtualKeyBoard can not be changed in the skin.  The need to specify the colours as decimal in the skin is a fault / deficiency of the code in skin.py and is outside the scope of the code for VirtualKeyBoard.

 

(The problematic code in skin.py that only allows the data in parameters to be int or float is currently being reviewed.)

 

Regards,

Ian.



Re: Language assistance requested... #593 littlesat

  • PLi® Core member
  • 57,062 posts

+698
Excellent

Posted 1 September 2018 - 11:11

Wierd as on all other location of the skin.xml the colors are in hex.... but I see here the parameter part is used and it was never intended to use it for colors.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Language assistance requested... #594 ims

  • PLi® Core member
  • 13,764 posts

+214
Excellent

Posted 1 September 2018 - 11:26

 I see here the parameter part is used and it was never intended to use it for colors.

yes, it was never intended for hex values (colors)...


Kdo nic nedělá, nic nezkazí!

Re: Language assistance requested... #595 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 1 September 2018 - 11:34

So add support for it?

diff --git a/skin.py b/skin.py
index e8d2f9d..5434e42 100644
--- a/skin.py
+++ b/skin.py
@@ -586,7 +586,8 @@ def loadSingleSkinData(desktop, skin, path_prefix):
                        try:
                                name = get("name")
                                value = get("value")
-                               parameters[name] = "," in value and map(int, value.split(",")) or int(value)
+                               hexint = lambda x: int(x[1:], 16) if x[0] == "#" else int(x)
+                               parameters[name] = "," in value and map(hexint, value.split(",")) or hexint(value)
                        except Exception, ex:
                                print "[Skin] Bad parameter", ex

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Language assistance requested... #596 littlesat

  • PLi® Core member
  • 57,062 posts

+698
Excellent

Posted 1 September 2018 - 12:10

Yes please...

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Language assistance requested... #597 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 1 September 2018 - 12:14

Support for load svg in ePixmap was implemented here: https://github.com/O...740b823ac2ea0f1

So now using the following in skins should work.

<ePixmap pixmap="skin_default/buttons/green.svg" position="140,0" size="140,40" alphatest="on" />

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Language assistance requested... #598 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 1 September 2018 - 12:44

This adds support for both "#ff000000" and 0xff000000. Both parsed as hex numbers with base 16.


diff --git a/skin.py b/skin.py
index e8d2f9d..3f6e357 100644
--- a/skin.py
+++ b/skin.py
@@ -586,7 +586,8 @@ def loadSingleSkinData(desktop, skin, path_prefix):
                        try:
                                name = get("name")
                                value = get("value")
-                               parameters[name] = "," in value and map(int, value.split(",")) or int(value)
+                               hexint = lambda x: int(x.replace('#', '0x'), 16) if (x[0] == "#" or x[:2] == "0x") else int(x)
+                               parameters[name] = "," in value and map(hexint, value.split(",")) or hexint(value)
                        except Exception, ex:
                                print "[Skin] Bad parameter", ex
@IanSav, can you confirm it's ok? Or you have another, better approach?
Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: Language assistance requested... #599 Huevos

  • PLi® Contributor
  • 4,621 posts

+161
Excellent

Posted 1 September 2018 - 12:53

This adds support for both "#ff000000" and 0xff000000. Both parsed as hex numbers with base 16.

 

diff --git a/skin.py b/skin.py
index e8d2f9d..3f6e357 100644
--- a/skin.py
+++ b/skin.py
@@ -586,7 +586,8 @@ def loadSingleSkinData(desktop, skin, path_prefix):
                        try:
                                name = get("name")
                                value = get("value")
-                               parameters[name] = "," in value and map(int, value.split(",")) or int(value)
+                               hexint = lambda x: int(x.replace('#', '0x'), 16) if (x[0] == "#" or x[:2] == "0x") else int(x)
+                               parameters[name] = "," in value and map(hexint, value.split(",")) or hexint(value)
                        except Exception, ex:
                                print "[Skin] Bad parameter", ex
@IanSav, can you confirm it's ok? Or you have another, better approach?

 

Is it possible to add colours to that? i.e. "red, orange, etc" like in other places in the skin.



Re: Language assistance requested... #600 IanSav

  • PLi® Contributor
  • 1,491 posts

+51
Good

Posted 1 September 2018 - 12:53

Hi Athoik,

 

This should be okay to start.

 

One small problem, we also need the preserve the data type float that also already exists in parameters.  That is, if there is a "." in the parameter try to cast the value as float.

 

Regards,

Ian.




11 user(s) are reading this topic

0 members, 11 guests, 0 anonymous users