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 :-( 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 constantly. 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 like that. 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, Riccardo ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
