1459 replies to this topic

[SpaceRat]

Well, why not ...

[athoik]

Thanks!

[sat2020]

hi

hows every thing?

whta is open webif  username and password for open webif?

thanks in advance

[Pedro_Newbie]

That's is a well kept secret, what is the sense of a username and password when you put it on the Internet?

 

Well to be honest just go to:

Menu -> Plugins -> OpenWebif -> Enable HTTP Authentication = no

 

That should solve your problem.

[Rick Hunter]

When you add a password in your root account.. you can enter the webif.

A sort of workarround, if you will not deactive the http authentication, add a new user (in commandline adduser) and give it a password. Then you can enter the WebIf with that username and password.

 

But.. using a username / password with a http stream is a bit strange.. the content is unencrypted.

[hemertje]

did you test it with the function "remote timer" ?

[Priskvark]

 

 

I have some questions about the interface of OpenWebif. Maybe you would prefer one post for each topic but I try this format.

 

TV Multi EPG. When this option is selected, then my browser (latest versions of Firefox & Internet Explorer) opens a new tab or I can chose to open it in a new window. For this new tab/window Webif has calculated the size and puts the EPG-information in it’s own scroll area. The scroll area consists of a page header, a channel bar, EPG-information and then the page footer with a horizontal scroll bar and a channel bar (followed by space with approximately the same height as the sum of the scroll bar and the channel bar). This looks very nice. But there is one thing that would make the user experience even better.

When the size is calculated, the footer with the horizontal scrollbar (the channel scroll) is always hidden and to see it you have to scroll down with the browsers vertical scrollbar. The channel scroll bar is frequently used and I would guess that this scroll bar is the main reason for putting the EPG information in its own scroll area rather than writing it directly to the main browser window. Is it possible to calculate the channel scroll area so the whole “page” is visible - including the page footer?
 

EPGRefresh window in Extras. It’s not possible to translate the EPGRefresh window in Extras. Is this a problem that must be solved in the EPGRefresh Plugin or should this be a part of the Webif translation (as AutoTimer needs a translation in Webif)?
 

Box Info. In the Box Info window are 3 phrases that are not translated by the software: none/IPv4-only network (confirmed). I guess this may be an issue also for: IPv4-only kernel, and IPv4-only Python/Twisted.
 

Recording LED. Lastly on my wish list is a new feature for the red LED light in the header of the main window. When you hover over the light you get the information “Recording status”. Would it be possible to extend this information to a list showing what channel is recording and the title of the recording?

The information is sort of available in the timer list but wouldn’t it be handy if you could see it on the LED? I don’t know if that information is hard/impossible to fetch?

 

[SpaceRat]

Please note:

For discussion about, suggestions for or reporting errors in OpenWebif, you might want to use github:E2OpenPlugins instead and open issues there.
No active dev of the OpenWebif uses OpenPLi, so what you report here might be overlooked.

However, I have fixed the translation issue concerning "none/IPv4-only network", "IPv4-only kernel" and "IPv4-only Python/Twisted" already.
If I break it, I also fix it

[SpaceRat]

EPGRefresh is also translatable now ...

[ims]

Yes, very nice. Only one problem, imho ... all must be translated 2x

[SpaceRat]

Yes, very nice. Only one problem, imho ... all must be translated 2x

Huh?

[ims]

 

Yes, very nice. Only one problem, imho ... all must be translated 2x

Huh?

 

Same strings are/was translated for enigma or for EPGRefresh etc ...

[Priskvark]

 

 

 

Please note:

For discussion about, suggestions for or reporting errors in OpenWebif, you might want to use github:E2OpenPlugins instead and open issues there.
No active dev of the OpenWebif uses OpenPLi, so what you report here might be overlooked.

However, I have fixed the translation issue concerning "none/IPv4-only network", "IPv4-only kernel" and "IPv4-only Python/Twisted" already.
If I break it, I also fix it

 

Thanks for yet another god advice how I may get the best results regarding OpenWebif questions and issues.
 

Of course I prefer to write where the developers read and can evaluate my suggestions. You have already taken care of the translation issues so I just transfer the other items to github:E2OpenPlugins.

 

[Priskvark]

 

 

 

Yes, very nice. Only one problem, imho ... all must be translated 2x

 

 

 

 

Yes, very nice. Only one problem, imho ... all must be translated 2x

Huh?

 

Same strings are/was translated for enigma or for EPGRefresh etc ...

 

 

I agree, it would be best if the interface to EPGRefresh would handle the translation. 

 

As far as I can see it doesn’t at the moment.Is that a problem that can be solved from within Webif it certainly would be the preferred solution.

On the other hand if the developers of EPGRefresh must do something to fix the issue (and they don’t want to or have the time) then why not use EPGRefresh to solve the technical task and do an extra translation to solve the user interaction in an acceptable manner?

 

[SpaceRat]

There are certain problems:

gettext is a pain in the ass

The default is to translate every identical original text to the very same translated text.
Sounds obvious, but rarely ever works out in practice, especially if the original language is as indifferent as English.

Just take "clear" and its possible translations to German for example:
clear (as in sky) = klar
clear (as in empty all input fields) = löschen
...


Now in context it gets even more frustrating:
clear water = klares Wasser
clear mind = klarer Verstand
clear sight = klare Sicht
...

None of those happens in OpenWebif of course, but they illustrate the problem.

Now you can imagine the problem to be even larger the larger the textual domain becomes:
While a text might be non-ambiguous within OpenWebif (or any other plugin) alone, it can (and will) become ambiguous as soon as gettext uses translations of other plugins or even a "unified E2 translation database".

As long as you seperate textual domains, you can at least reliably find out where ambiguities are and then avoid them using translations with context.
If you however throw them all together, you are lost in hell, because you would have to compare the translation of plugin A to the translations of every variant of every other plugin or E2 fork.

Merging the textual domains of multiple parts of E2 and its plugins is a no-go.
For most languages, two words alone are proof enough:
"schedule" and "programme".

If you don't get the idea, imagine plugin A importing the schedule for your tv stations from a web site and plugin B telling you about train connections ...
A is a "Programmvorschau" in German and B is a "Fahrplan" in German, probably least languages use the same word for things that different but English does.

Throwing translations of different programs together will make you wish you had translated the same text three times instead of just twice.

We would already need contextual translations (gettext supports that, but its more work and almost nobody uses it) by now and it would become much more of a problem when merging translations.

[SpaceRat]

BTW: gettext would work much better if the original language was Greek (and even worse if the original language was Japanese or Turkish).
However, in all three cases we would have much fewer translators

[Priskvark]

 

 

 

 

 

 

 

BTW: gettext would work much better if the original language was Greek (and even worse if the original language was Japanese or Turkish).
However, in all three cases we would have much fewer translators

 

At least I would give up (or wait until the English or your German translation were published and then be back to where we are now...   )

 

In your post you describe the pains of all translators well. That’s why, though it will not solve all problems, I think it would be better if each plugin had its own translation not interfering with the same words in another context.

 

Then Webif in the Autotimer window could use schedule= Programmvorschau and in an imaginary window TrainTimer could use schedule=Fahrplan  without interfering with each other.

 

I am not familiar with python and enigma so I really could not say how things work inside but it seems like the Setting page uses translated strings without the need to translate it separately for OpenWebif. If that is so then it’s a good example how I think it should work with all "server" plugins.

 

Well my views are based mostly on speculations and I am now (at last) aware of that you are a named author of OpenWebif so if I got it all wrong (the Setting example) I just appreciate if you take the time to straighten things out.

Edited by Priskvark, 2 November 2014 - 01:16.

[SpaceRat]

I am not familiar with python and enigma so I really could not say how things work inside but it seems like the Setting page uses translated strings without the need to translate it separately for OpenWebif.

That happens if the same string has already been translated for some other plugin or inside Enigma2 itself and if the "whole thing" is considered as one textual domain.
If you are lucky, the translation fits.
If not, you are in deep shit (If you consider a proper translation to be important).

One of the bad aspects of textual domains larger than a single component is, that you do not necessarily see if you are done with translating.
For some strings translations from other plugins would jump in ... as long as you have that plugin.
For someone else, who doesn't have that other plugin "donating" the translation, the original text would appear untranslated.

BTW: That's not a Python thing, gettext is a "GNU API" widely used in the Linux world (with the same problems everywhere).

[druciak]

Is there any API documentation for this interface? I could not find it on github.

[SpaceRat]

You mean gettext?

https://www.gnu.org/software/gettext/