[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]
Kern Sibbald wrote:
> On Tuesday 20 May 2008 13:19:24 rghetta wrote:
>> - 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
> Qt tr().
> 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.
bat uses the library, so we can't avoid gettext.
>> - 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' ...
Well, a translator will translate 'Append' even when using a single
char encoding, because she will translate the string in the conversion
routine, not the status code.
Using directly as string like 'Append' is error-prone when you need
to mix translated and untranslated uses of that string like bat does.
Besides, a single char can be converted in a C enum and copied, used in
switch(), if() and so on, while a string cannot.
If you prefer to use a string, I will use it, obviously, but I'm still
>> 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".
Some job status codes are decoded only by the routine, and missing from
And jobstatus_to_ascii() converts JS_Terminated as 'OK', while the
status table has 'Completed successfully'.
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".
>> - 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.
Sorry, I messed up. What I meant is that if someone wants to have all
messages in a specific language then he should run all programs in that
>> 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.
>> 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.
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.