Translating images?

[VS]

you're no worse off than before (...) additional feature

Agreed.

Instead, when the implementation is approved, I intend to start bothering artists for assistance. (...) if we say pretty please

Why do I feel less optimistic about this? But once the materials and guidelines are available, most of the work will be easier.

[torangan]

Don't underestimate the work to get something like the main logo text rendered. I remember the development as quite a lot of work for Jetryl. But even if it "only" improves the maps, l10n will be better off for it.

[caslav.ilic]

Don't underestimate the work to get something like the main logo text rendered. I remember the development as quite a lot of work for Jetryl.

*gulp*

But even if it "only" improves the maps, l10n will be better off for it.

And the screenshots, the screenshots :)

I have some experience with ImageMagick and can offer some help

Hm, even if of limited assist, at least a conceptually rather clean possibility for some automation just came to my mind. It's about the partial overlay images. Right now, I've in mind that whoever edits the image marks the overlay cut by hand, but -- could it be possible to make an automatic diff instead? So that both there is no need for manual cuts, and the overlays get to be of minimal size.

In fact, while manual cuts are probably limited to natural images for that, i.e. maps, an auto-diff could be applied to any image, including in-game screenshots (the only place where overlays are not possible is for HTML doc shots). This would reduce those estimated ~700 kB/language even further.

[caslav.ilic]

As it stands now, is there a conclusive sway? This is the way I see the current state of deliberation:

• means of specifying and acquring localized images at runtime -- automatic by l10n/ subdir system, smallish patch
• large size of image data, necessity to split packages -- probably eliminated, through use of map overlays
• non-discovery and use of outdated localized images -- hopefully eliminated, but the tracker script is not proven in practice
• teams' capability of producing localized images -- assits to be examined with artists, some automatic rendering ideas floating

Did I miss any other important point?

When the conceptual elements would be judged acceptable for try-out by the "red-named" folks :) I would move to inquire in Coder's Corner about the validity of the patch itself.

[torangan]

You've got my support for the concept and I guess a well done patch will go through. I just don't expect to many people supplying localized overlays so the size issue won't appear for some time.

[mihoshi]

I'm not sure that it`s a good idea for thousands of Wesnoth players to download extra ten mb each, for something even one of them hardly needs.

[torangan]

Translations are already a significant chunk of the download size. I guess it'll go as for other projects. Once the size of translations reaches a critical point a packager will start to put them into seperate packages. Then you'll only have to download what you need. But before this goes off topic even more: the official distribution is the source package. Binary packages are created by certain volunteers and only hosted by the Wesnoth team. If you want different packages, do NOT ask the Wesnoth team. Ask the packagers.

[Noyga]

I'm not sure that it`s a good idea for thousands of Wesnoth players to download extra ten mb each, for something even one of them hardly needs.

If you compare to our music, it's the size of one or two song, nothing more...
There isn't many places where this would be used so it would not result in a very big size increase compared the the whole package.
IMHO the main issue is to define how this would work if we want something flexible enough.

[caslav.ilic]

IMHO the main issue is to define how this would work if we want something flexible enough.

Out of the four points I summarized above, you mean flexible with respect to the last point (how to produce localized images), or perhaps you also see something "rigid" with the other three points? (Or we forgot an issue to take into account...)

Most importantly, does the technical implementation itself merit more flexibility, or you'd say I could proceed with presenting the patch?

[turin]

If you compare to our music, it's the size of one or two song, nothing more...

Yeah, but people listen to the songs. If the download included two 5MB .ogg files that were empty, I would be rather irritated.

[caslav.ilic]

For the record, there are presently 17 packed megs of, by the same criteria, empty text files, which expand to 47 megs of empty binaries when installed :)

[torangan]

Stop worrying about size, that's a simple packaging issue.

[caslav.ilic]

Another go-ahead from persian-reds? Ivanovic, Noyga?

[ivanovic]

Ignore size as a real problem.

The main aim should be to make it reasonably easy to use even for translators that are not graphics artists. I have no idea if we can eventually automatically create the images, so for now we got to go the "by hand" method. What I would propose to try:

Just go to replace complete images.

This is rather simple in the ingame help where we just have to replace screenshots. For the manual it is a little more difficult, we have to check what we have to do to have the images "translatable", but should be reasonably possible. The main problem are all those fancy images with "embedded" text like eg maps (this is the only place the ATM comes to my mind). Somehow we should try to find a way to split the images into base image and label and have those single labels be put on the map. Those can then be "marked translatable" so that the single labels can easily be replaced by other images.

This will probably require to redo many of the maps we currently have like it was done for trow. Some of the stuff needed for it (and for creating those overlays, at least I think so) are in our svn rep under branches/resources/cartography-tools/ .

And with this back to the size stuff:
All this would be about is some small subsection of a whole screenshot and stuff like map labels. Those will *not* take too much space, so it is no real issue in my eyes at all.

[caslav.ilic]

Ignore size as a real problem.
[...]
[...] What I would propose to try:
Just go to replace complete images.

Even if size is not a real problem, there's basically no reason not to use the overlays as I proposed. Once the complete image is ready (one way or the other) to make an overlay out of it is trivial, even if manual. And it's also conceptually clearly possible to do automatically -- just haven't found a tool yet :) (perhaps time for me to look into Gimp scripting...)

At any rate, overlays are an "orthogonal" feature in the patch I proposed. Overlay is procured as a fallback, a secondary try if the complete image is not present. So if all images are complete, no problem there.

[...] For the manual it is a little more difficult, we have to check what we have to do to have the images "translatable", but should be reasonably possible. [...]

Right. I estimate it will take me 15-30 minutes to write a script which modifies the generated doc HTMLs so as to point to localized images. Other than this script, if the l10n-subdir system is used as for all other images, no extra infrastructure will be necessary.

The main problem are all those fancy images with "embedded" text [...] "marked translatable" so that the single labels can easily be replaced by other images.

This will probably require to redo many of the maps we currently have like it was done for trow. [...]

I'll reiterate that I personally don't believe in auto-overlays, in the following sense: they are a compromise with art. The artist may be forced to do what he wouldn't do otherwise, for the sake of localization only; e.g. I'd find it rather unlooky if all text on the main map of Wesnoth would be superimposed like in TRoW.

Instead...

[...] Some of the stuff needed for it (and for creating those overlays, at least I think so) are in our svn rep under branches/resources/cartography-tools/ .

Way to go! That was one thing I meant to pester artists with; after looking at this data, now I only need to additionally ask how to produce the main-menu look out of the clear-look map, but I hope that's just applying few effects.

So, what I intend to do is to "normalize" the main map's source image, i.e. to put it in a form best prepared for manual l10n, without all the non-l10n necessary elements that it has now. Then, describe the steps in Gimp to modify the elements, to make expected small adjustments, and prepare the final image. And so for other "types" of images. All this perhaps best on one wiki page, and we also keep one sticky thread for discussion.

* * *

But, to go there, first we need to commit some code, which would be my present focal point :)

And it seems to me that the presented l10n-subdir system on the code side, plus the tracking script to keep them in sync, is appropriate regardless of how the localized images are actually produced (drawn manually, complete or in overlays, static autorendering, dynamic overlays like in TRoW...)