[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] RFC: bat translation [was: Patch: formatting for media and storage trees on bat]
On Tuesday 20 May 2008 13:19:24 rghetta wrote:
> 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.
> Hello all,
> 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 :-(
Well, unfortunately none of us have much experience in translating apps.
> 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.
Yes, this is a bit of a pain. In cases, where the code is within Qt type
files, we simply need to convert from the Bacula core _() convention to the
For certain files that don't have Qt included (if there are any), we should
try including Qt translation headers and switch to using the tr() code.
> - 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.
Well, I would say that bat must just pass those messages on to the user
without touching them.
> - the database itself hinders translation (and portability) somewhat due
> to its use of enum columns, e.g. volume status.
Well, I find that fields that are numeric rather than strings make Bacula much
harder to maintain. It really isn't much harder to translate fixed strings
like "Append" than if it were an integer. It does take a few more CPU cycles
> 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.
As I mention above, Bacula uses both practices, and I find the single
character encoding to be *much* harder to read and understand in the code.
The big work in any body of code such as Bacula is maintenance, so I prefer
to lean toward making maintenance easier. For translation, we can work
around these problems. Besides for a translator, IMO, it is much easier to
translate "Append" than 'a' ...
> 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.
I don't know what you mean by "Not aligned".
> 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.
Yes, this is a good idea, but in general, what Bacula returns that is used
pragmatically (in the code) should be in English. If we have strings that
have to be recognized by bat that are coming from Bacula that can be in any
language, it will be a real nightmare.
> - 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.
That is not a good assumption. You should assume the contrary that bat will
connect to different Directors and that they may or may not be translated.
Imagine that you are the IT director for the world, and you want to use bat
to connect to Directors in 10 different locations around the world in
different parts of your company. The above assumption will be catastrophic.
That is why I say that anything that bat "parses" should be in English, and
not translated in Bacula.
> 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.
Yes, we need to ensure that the translation of those messages are all done in
bat not in the Director.
> - 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.
The user may "see" certain things in English -- that is no problem as long as
the key parts of the dialogs are properly translation.
> 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.
I don't see that as a problem.
> In the longer term bat probably will switch to dot commands and consume
> directly the resulting status, presenting a "cooked" result to the user.
Yes, that is where we are heading.
> 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.
Bat is something that is evolving, and at the moment, we are going on the
assumption that you must use bat with the same version of Bacula with which
it was release.
> 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
> like that.
Many of the dot commands are implemented on top of the other as you say.
There is just an if statement when it comes to displaying something. In
other cases, the commands are very different or not even available to the
user as a regular command. I think we don't have much choice if we want the
> Oh well, perhaps when we have a full set of machine parseable dot
> commands, we'll reimplement the standard commands on top of them.
There really is not a lot of duplication, and if there is we can do as you
> Phew. That's was it. I hope to have included everything.
> With apologies for the length,
With my apologies for the delay in responding, and I hope I answered your
questions and gave you an idea of our current concept of where we are going,
which will surely evolve a bit as we gain more knowledge about translating.
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.