[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bacula-devel] RFC: bat translation [was: Patch: formatting for media and storage trees on bat]
Kern Sibbald wrote:
> Also, Riccardo, there may be a project that would interest you, and that is
> translating Bat. We have it partially translated into French, but the
> problem is that we have not been careful enough in the source code to flag
> all the translatable strings, and much worse, in a number of places, we have
> strings coming from the Director that may or may not be translated depending
> on the state of the Director. This makes doing any translation of bat a very
> delicate and difficult job. It really needs a lot of thought.
> It seems to me that ideally, the API should all be in English and never
> translated (currently parts of it may inadvertently get translated), and then
> the Director should inform bat what language the main Director strings are in
> (i.e. are they in English or Italian). That could help bat making
> intelligent choices of how to handle things -- particularly column headings
> and the such.
first, allow me to say that I don't have experience as a programmer in
translating apps, so I'm afraid my help here will be limited.
Besides, I can contribute only on my very limited free time, so if you
need something fast, I'm not the right man :-(
Anyway, not being sure to understand the current status of bat
translation, I'd like to recap things as I see it. Please point out any
misunderstandings on my part.
What I'm going to say is sure obvious to most, please be patient, I'd
like to have everything covered.
I'm probably also missing a great deal of important details, help from
developers will be very useful.
You will see that the issue of backward compatibility comes us almost
Translating bat needs work at different levels:
- most strings used by bat can we wrapped at QT level with tr(). It's
mostly done (on trunk). Some have to be rewritten, e.g. those created
by concatenating partial messages, or referring to multiple entities.
- code lifted from other parts of bacula or located into the library
uses gettext. This could lead to different translations since we need to
use two catalogs, two translation tools, etc.
- database fields can contain messages (e.g. job logs).
IMHO bat can't and should do nothing here. The message(s) should be
translated when writing.
- the database itself hinders translation (and portability) somewhat due
to its use of enum columns, e.g. volume status.
In those cases you can still set up a dummy translation function just to
make the strings available to the translator, but is very ugly.
The single char encoding used for job status is a much saner approach.
Unfortunately, jobstatus_to_ascii routine and Status table aren't
aligned. Bat currently uses the status table, and switching to the
routine will change the displayed strings.
While the table strings are better suited to bat, simply using them also
in the routine could affect users. For example, mail headers are likely
to become "Completed successfully" instead of just "OK".
Note that we should add to the library functions to return not only a
user message from a status code, but also all possible messages and
codes to fill the combo boxes.
- director messages and statuses. In most cases bat doesn't parse them,
so they can be displayed as-is. I assume that one will run bacula with
all programs using the same language. Having bat reinterpret and
translate director messages seems simply not feasible.
Obviously bat should try to avoid using possibly translated director
messages to enable menus, color fields, and so on.
- director commands. IMHO they should not be translated at all (are
those the API you referred to ?).
Now bat relies on them being in English, but the user "sees" the menus,
so this doesn't matter (much). Rewriting bat to handle translated
commands will be a big work with a little reward.
Every command issued by bat is now displayed in the console along with
the director response. This could expose untranslated strings to the
user, but it seems unavoidable, at least in the near future.
In the longer term bat probably will switch to dot commands and consume
directly the resulting status, presenting a "cooked" result to the user.
Again, doing so will likely break backward compatibility, given that
today most commands haven't a dot equivalent, so older directory are
unlikely to work with newer bats.
I'm a bit worried about the whole issue of dot commands, though. Having
two set of commands for doing more or less the same things seems a bit
wasteful, unless you implement one on top of the other, or something
Oh well, perhaps when we have a full set of machine parseable dot
commands, we'll reimplement the standard commands on top of them.
Phew. That's was it. I hope to have included everything.
With apologies for the length,
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.