Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No need for visual Hebrew any more #1705

Closed
Omertron opened this issue Mar 15, 2015 · 9 comments
Closed

No need for visual Hebrew any more #1705

Omertron opened this issue Mar 15, 2015 · 9 comments

Comments

@Omertron
Copy link
Member

Original issue 1706 created by Omertron on 2010-11-11T12:13:29.000Z:

Popcorn Hour has implemented in their 02-04-101104-21-POP-408-000 firmware, BIDI Hebrew support, so conversion to visual Hebrew is not needed anymore. The skin hebrew-visual is for backward compatibility.

@Omertron
Copy link
Member Author

Comment #1 originally posted by Omertron on 2010-11-11T15:03:04.000Z:

Daniel,
Can you take a look at this submission please?

@Omertron
Copy link
Member Author

Comment #2 originally posted by Omertron on 2010-11-11T15:19:19.000Z:

sure thing, i'm on it.

@Omertron
Copy link
Member Author

Comment #3 originally posted by Omertron on 2010-11-26T09:04:55.000Z:

Wow, 23 people starred this issue.

Daniel has looked at this issue. I'm not sure that I understand what the difference between what we have now and these changes are?

Does the current skin not work with the new firmware?
Does the new skin look better?

@Omertron
Copy link
Member Author

Comment #4 originally posted by Omertron on 2010-11-26T11:50:24.000Z:

The new skin is an exact duplicate of the original skin with one difference which is all the Hebrew words that appear in the skin are reversed for example the genres words as I previously said this is not enough to justify a skin duplication. It will make the code maintenance harder. One elegant solution will be to store the words of the skin in another place meaning not inside the xsl file and dependent on some property the skin should decide whether to reverse the words or not.

@Omertron
Copy link
Member Author

Comment #5 originally posted by Omertron on 2010-11-26T15:47:03.000Z:

Perhaps Yamj should create "Buttons" that have the wording *(whatever language) applied through an overlay creation of a PNG file...the wording could be supplied from movie jukebox property settings and the the button selectable in the skin could simply refer to btnALL.png or btnMOVIES.png that would have been created with the proper words/language.

@Omertron
Copy link
Member Author

Comment #6 originally posted by Omertron on 2010-12-02T18:28:56.000Z:

Any plans going forward with this issue? As of the moment, using the latest NMJ firmware and a formal version of YAMJ renders reversed Hebrew in movie names and plots under YAMJ different screens and makes it practically unusable. Thanks!

@Omertron
Copy link
Member Author

Comment #7 originally posted by Omertron on 2010-12-03T08:20:10.000Z:

Stuart,
Currently the 200 devices shows the hebrew strings inside the htmls reversed. But the 110 devices show it correctly (as before). if we insert this "non-reversed" skin, we solve the problem for all 200 devices but we force all 110 users to switch to the backward compatible skin. I am all forward for this change, but it needs to be documented someplace easy to note all 110 devices to switch the skin they are using. I hope that Sybas will provide a fix for this in 110 also, so we will be able to delete the old skin. Any how i think that we don't need to support/maintain the old (reversed) skin any more.

What do you think ?

@Omertron
Copy link
Member Author

Comment #8 originally posted by Omertron on 2010-12-03T08:31:53.000Z:

What I'd like is the skin to use a skin.property/option that you could set so that the skin would change the direction as appropriate.

That way we could have one skin, with a property that switched between the two as needed.

@Omertron
Copy link
Member Author

Comment #9 originally posted by Omertron on 2010-12-05T11:05:36.000Z:

This issue was closed by revision r1986.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant