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 > though. > >> 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 unconvinced. >> 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 the table. 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 language. >> 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. OK >> 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. OK Greetings, Riccardo ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
