I've added my comments below, but if it's just 24 strings per file maximum, I don't care enough to argue, *but* I can assure you this number will grow very soon (once people will be able to translate strings in edj). Please read my comments anyway, maybe you'll get convinced. Furthermore, I have a compromise, maybe implement edj inclusions and add an edj.d dir for each edj so it'll be able to load all the translation edj's (which will be either in one edj, or split to several).
On Thu, 2010-08-26 at 17:50 +0200, Cedric BAIL wrote: > 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. Just package a theme + it's translations (if any) in a tar file and let the "theme installer" do it. > 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 ? I'm no gettext expert, but I bet there's a way. If not, maybe it's a good idea to include translations in the same .po (yes, this will mean you won't be able to add new strings that were not in the original edj without contacting upstream, but is this that bad?). This makes everything a lot more simple and nice. > 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. I don't know enough about gettext, I just know that gettext is used in many projects. I wonder, how do they solve it in GTK+ (and glade)? (Same case exactly!) > 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. Even if you only talk about the default theme, it's the default theme per application. Do you agree (it's a fact) that there are different packages for each locale in all the major distros? Now think about the following (I assume the user is French): You ship the edj with *all* of the translations by default and a user did not install the French translation package, so he'll get a pretty incomplete translation (only a couple of labels) and will assume this is the state of the translation. A more "active" user will probably rant about it in a forum and will be told to install the locale so he'll get the theme and be pissed, the others will just get a barely translated interface and will assume e17/linux/that app suck. > 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. Cons: As a developer/translator: 1. You have 2 translation files you need to remember to update. As a user: 1. What I explained just above about the confusion with the translation package. 2. You'll update your theme package (will be updated by your package manager) automatically even if only translations change. <--- getting all of those .png's for nothing. > > 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. As mentioned above, I honestly think those numbers will grow a lot once you'll allow translations in .edj's. Furthermore, the point about having to re-download the whole theme package (incl. images/videos/whatever), which will be done automatically by the package manager, just because someone changed a word in the translation in a language I've never heard of, sounds pretty annoying to me. -- Tom. ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
