Re: [E-devel] Edje translations - Why they shouldn't be inside .edj's

[Cedric B. <ced...@fr...>]

On Thu, Aug 26, 2010 at 5:00 PM, Tom Hacohen
<tom...@pa...> wrote:
> On Thu, 2010-08-26 at 16:32 +0200, Cedric BAIL wrote:
>> Nothing prevent you to ship Edje file with a limited set of
>> translations. They will be in separated eet section. So you can
>> remove/add/modify them at your convenience. The problem of shipping
>> Edje file with separate translation, cause issue with such concept
>> like Exchange. It complexify the work of user as they need to download
>> the theme they like and the translation they want. They also need to
>> install them at different place (something that could be handled with
>> a direct interface in each application or with a packaging script). So
>> yes, it's a trade off, but you have the choice. Nothing prevent you to
>> put the infra on the server to automatically ship edje file with just
>> the translation the user want by just removing the eet section that
>> are not requested. It will always remain easier to distribute one file
>> than many.
>
> There's a pretty automatic way of separating translations to different
> packages in many build systems, this will have to be adjusted to support
> extracting the pot's from the edj's, removing them, and packaging them
> differently, this is a hassle no one will bother doing. So no, I can't
> remove them at my convenience. You can easily create a ~/.e/translations
> directory and put your gettext files there. It's easier and cleaner to
> adjust exchange to support that than adjusting all of the other pieces
> of software in the world. Plus, you get the added advantage of easily
> manipulating gettext files.

Do you really expect user downloading theme from website to move the
file in ~/.e/translations ? Right now, when you import a theme in
edje, you just need to select an edje file and you get your theme. You
have nice preview too. If you want to include translation your way,
please explain how user will handle that ? Adjusting exchange doesn't
change anything at all, you still have to move your file around on
your own disk. Nothing like, one file to download and try.

>> Putting translation inside edje file just make it easier to user. I
>> don't expect people to get all the possible theme from there distrib,
>> but more from online source. So we will use the same gettext file
>> format, that could be extracted from any edj file (anyone can
>> contribute with normal gettext tool to the translation of the edje
>> file they are using). And last point, I believe that interface should
>> be localized too, some theme just doesn't make sense for some culture.
>> So by shipping edje file targeting one culture and the translation
>> related to it, I think it make sense.
>
> That's cool (although I believe completely unnecessary, but really no
> idea as I don't speak all the languages in the world), but completely
> not related to the issue at hand. Actually, since themes may make sense
> in one culture but not in another, you can't expect a themer, from
> culture x, to understand the culture y, so if the guys from culture y
> think that x does not understand them, they should create their own fork
> of the theme, and not merge it into a big binary blob that contains two
> interfaces which only one of will be used per system. The only real
> adjustment I can think of (which can and will be done automatically) is
> UI mirroring, but that does not require a change in the theme, only in
> edje.
>
>> And maybe I am wrong, but gettext expect to see translation in
>> /usr/share/local a place that users are not allowed to write to.
>
> man bindtextdomain

Maybe I am wrong, but does it handle multiple path for the same
domain. From what I read, I don't think so. So how do you handle
translation for system theme and user theme, where translation are
obviously not installed in the same directory ?

>> Edje is designed to be a package that include all the needed ressource
>> to correctly display a theme for any app, including translation inside
>> is just one more step on this road.
>
> Translation outside is also one more step on this road, the difference
> between those two steps that the former is working on reinventing the
> wheel, and the latter is driving a car. Really no need to invent
> something already so widely used.

I don't want to start a troll here, but it's not because a lot of
people are using a tool, that it is a good solution that fit our need.
In our case, using gettext does trigger a lot of issue for user. And
it's not reinventing a wheel as gettext is not designed to handle this
our use case.

>> No need to duplicate, just remove before sending if you are really
>> short on bandwidth.
>
> Back to my first comment: No distribution maintainer will bother to rip
> your edjs apart and distribute them separately, and even if someone
> will, they'll have a lot of big (because he has to duplicate the whole
> edj, including pictures) packages in there server. And installing two
> different locales on a machine using a package manager will become
> impossible, you are really just making the maintainers life a living
> hell, and no one anywhere in the world in any situation what so ever
> will be willing to ship all of the locales in one package (edj).

Ok, here I disagree, I don't expect distribution to deliver more than
the default theme here. That's maybe why we are not agreeing on the
solution, we are not agreeing on the use case to start ! For
distribution maintainer, I do expect them to ship the default theme
with all possible translation they target with there distribution in
the default dvd. This default theme will be big anyway du to image
ressource, and text shouldn't increase the size that much. Remember
that just text attribute in edc are localizable. We are not speaking
about translating app, just the content of a theme that the app is not
and should not be aware of. And it should work easily for all users in
all apps.

> I'm thinking as a package maintainer and a developer, I have strong
> objections when wearing either hat.

As a developer this solution change only one thing, you don't need to
care where your user put there file, just open an edj file and string
will correctly show up. That's all. As a developper and an user, I
only see pro. As for maintainer, I don't think they will care that
much about splitting edje file and I don't think it will be really
needed.

As I don't like to speak without numbers, translating E default theme
require around 24 strings to be translated, Elementary 3 and Enki, the
only app I know about that use edje and edje external to the layout,
around 20 strings. You are speaking about reducing something like 20KB
(20 strings * 13 characters * 80 lang) when image make edje file in
the MB range. I really don't want to increase the complexity of using
edje file for such a small win.
-- 
Cedric BAIL