Mirroring of layouts for Arabic and other right-to-left languages
Pär Spjuth
Since we are also working on this on a parallel track (and that is a
bit unwanted from all sides) perhaps we should share thoughts and
observations on this topic, hopefully ending up not too far from each
other?
Actually we have some experience on using the inheritance model. Our
first version used that. However, we encountered some problems which
led us to remove it completely:
1. Inheritance does not relate strongly to any other concepts in the
View-graph when it comes to non-numeric attributes, which made it hard
to explain, thus making it easy to accidentally misuse.
2. Since we had inheritance as default unexpected RTL results were
quite common when layout files were stitched together using code
(which seems to be common).
3. Since all "legacy" applications need directionality set to "none"
it has to be explicitly set to "leftToRight" in the theme for an
application that should support RTL (unless you which to state it in
every layout), and applying a theme effectively kills the inheritance
of values down the graph.
By this I'm not saying it won't work under other circumstances :)
About the naming problem I kind of agree. Left is left. Before is
relative. Using automatic mirroring needs the API to move up one
abstraction level. Since the current API level allows applications to
be very hard wired to specific device setups I think a higher
(voluntary) abstraction level could do some good. Especially when it
coexists with the current level. Since an application using the
"directionality" solution does however have to explicitly state its
compatibility with the mirroring algorithm hacked up applications that
combine both the View-framework and home-made pixel based solutions
are not messed up, they just have to be made somewhat cleaner before
they start using the mirroring feature.
What other concerns do you see?
Thing is that we already use the technique of mirroring the layout and
it works really well (as far as our language experts can tell). I
could however see somewhat neater ways to do things, but that would
require quite a lot of refactoring of the framework and I don't think
that is extremely appealing at this point in time.
Regards,
Pär Spjuth
Sony Ericsson Developer
Romain Guy
> View-graph when it comes to non-numeric attributes, which made it hard
> to explain, thus making it easy to accidentally misuse.
Do you have more details about this issue?
> 2. Since we had inheritance as default unexpected RTL results were
> quite common when layout files were stitched together using code
> (which seems to be common).
I don't see this as a problem with inheritance, just that setting it
as the default behavior might not be the correct way to do it.
> About the naming problem I kind of agree. Left is left. Before is
> relative. Using automatic mirroring needs the API to move up one
> abstraction level. Since [...] they just have to be made somewhat cleaner before
> they start using the mirroring feature.
In my experience you cannot really throw an RTL switch and expect your
app to behave nicely without testing it. Since RTL will be opt-in
because of backward compatibility, I agree with you and I think it's
perfectly acceptable to expect developers to clean up their apps. This
is somewhat similar to what we went through with multiple densities
support.
> What other concerns do you see?
> Thing is that we already use the technique of mirroring the layout and
> it works really well (as far as our language experts can tell). I
> could however see somewhat neater ways to do things, but that would
> require quite a lot of refactoring of the framework and I don't think
> that is extremely appealing at this point in time.
I understand your point of view but anything we do will be set in
stone for the foreseeable future. I would be very much against
choosing a solution because it's the easy one and make everybody's
life even more difficult down the road when we want to start doing it
the right way.
--
Romain Guy
Android framework engineer
roma...@android.com
Note: please don't send private questions to me, as I don't have time
to provide private support. All such questions should be posted on
public forums, where I and others can see and answer them
cibu cj
Is there a design doc other than the change description? For example,
what would be the difference between directionality=leftToRight and
directionality=none ?
Pär Spjuth
The directionality attribute basically provides the layout framework
with some metadata that must be provided by a human, i.e. in which
direction the end result is supposed to be read. Since the layout
framework always uses a coordinate system that has a horizontal
component which increases as we go right the directionality
information is necessary to be able to identify when a layout should
be mirrored.
E.g. I design and implement an application primarily for a LTR
language, say, English. But I also want it to work for Arabic. So, to
not have to create and maintain an extra set of layouts I simply set
directionality="leftToRight" in my application theme. That way it will
be applied to all ViewGroups in the application and the layout
framework will mirror it when Arabic is used (this includes scrollbars
and behavior of framework views/widgets).
The same example can be applied to the opposite use-case, where an
application layout has been primarily designed for Arabic but should
work with e.g. English as well. In this case
directionality="rightToLeft" and the framework thus knows that it
should mirror the layout when a LTR language is used.
Some elements in a layout has no real directionality, e.g. the screen-
lock slider or buttons placed in the corners of the screen. In those
cases we do not want the framework to fiddle with the layout so we set
directionality="none".
This solution is based on a minimal set of changes to the framework,
not reworking the fundamental layout model, since that kind of
refactoring is not practically available without close cooperation
with you Google guys :) In other words I totally agree with you Romain
that the final solution should be a good and well worked out one, even
though we do of course prefer that it involves equal or less work to
use than our uploaded one.
Before detailing the observations we've made using the solution above
I just want to check how far from your "slightly different" solution
it is. Just so I don't start describing problems that does not really
apply. Is it a different approach from the directionality design? Or
just different when it comes to how to perform the mirroring? (i.e.
not using leftPadding etc)
Regards,
Pär Spjuth
Sony Ericsson Developer