On Sun, Oct 10, 2010 at 5:08 PM, Khaled Hosny <khaledhosny@...> wrote:
> On Sun, Oct 10, 2010 at 04:52:23PM +0200, Lars Lindner wrote:
>> On Sun, Oct 10, 2010 at 3:36 PM, Yaron Sheffer <yaronf@...> wrote:
>> > Hi Lars,
>> > thanks for the explanatioln, but Adrian already told me that the strings are
>> > inserted into the XSLT files correctly. Now that I have compiled the code
>> > myself, I can also see that.
>> > But my question was different, and now I can also answer it :-)
>> > Text that is rendered through the XSLT files does NOT inherit the
>> > directionality attribute of the overall application. For example, the
>> > (translations for) "Feed:" and "Source:" still appear on the left hand side.
>> > There are several other examples. One possible solution is to have
>> > per-language XSLT files, but it's obviously not the right way to do it.
>> > Screenshot attached.
>> > [...]
>> The heading of the article view is a HTML table rendered by
>> Webkit. In the <td> element we leave the "dir" attribute undefined.
>> I'd guess RTL auto-detection doesn't work.
> I don't think WebKit have a paragraph level RTL auto-detection feature, in
> HTML you have to explicitly set the paragraph direction or the default,
> which is LTR, will always be used.
>> Or we have something
>> extra to do to tell Webkit that we are in an RTL GTK setup.
> The problem is not confined to headers, most feeds don't have explicit
> dir attributes set and thus RTL feeds are also rendered LTR and if the
> text is mixed RTL and LTR (like most technical texts) it becomes near
> impossible to read. So I think a more general paragraph base direction
> detection solution in liferea is needed, I recall this being discussed
> while ago but I don't recall what the decision was.
Well I can say what the code currently does: We do RTL detection
for all item and feed titles and ensure the direction inside feed and
item list is correct.
Until now we did rely on the HTML widget auto-detecting RTL, which
worked pretty well when we went with Gecko. It isn't since running
The problem is that we use gettext and some XSLT to merge the
translation into the XSLT stylesheets used for rendering. I doubt
this mechanism can be enhanced to auto-detect text direction
and insert additional direction hints. I believe the current design
isn't able to handle it. A much more complex one would be needed-