Forum OpenACS Q&A: Importing catalog messages

Collapse
Posted by Claudio Pasolini on
I recently installed the dotLRN alpha tarball and wanted to change locale from the default en_US to it_IT.

The first problem encountered is that clicking on 'Change locale' doesn't offer any choice but en_US. So I choose 'Administration' and the table 'Installed Locales' shows that only en_US messages are translated, even if the catalogs contains many translated messages for various languages.

I then searched the docs and found a wonderful package translation guide, but I missed the installation procedure and so I tried clicking 'Import messages from catalog files to the database' in the dotLRN package, without success.

Looking the data model I then realized that perhaps I needed to set the flag enabled_p to true in the ad_locales table and so I did.

I then repeated the 'import message from catalog' step and this time I got the expected result and then continued visiting the relevant packages, clicked 'Internationalization' and Import messages from catalog files to the database'.

I'm sure I've missed something and that there is an other simpler way: can someone put me on the correct track?

Collapse
Posted by Tilmann Singer on
You can enable locales in the acs-lang admin UI by clicking on the checkbox-like thing in the column 'Enabled'.
Collapse
Posted by Joel Aufrecht on
There's a bug pending so that clicking enable will auto-load the necessary files.  However, we still have the problem that there's no visible link from the place where you change your locale (and discover that there aren't any choices by default) to the place, which is administrator-only, where you enable the locales that are already in the distribution.  One fix would be to enable all of these locales by default.  Drawbacks: slows down install, could complicate future upgrading.  What do people think?  Most software (like linux installations) seems to offer a page of language choices that you can check during install.  Should we go this way, which complicates the install process, or just enable everything we have?  I'm inclined to the latter - all the translators have done so much work, and it differentiates us from some of the competition, so why should it be hidden behind two different invisible doors?
Collapse
Posted by Tilmann Singer on
Wouldn't enabling all become more and more demanding on the resources of the machine when more message keys and more languages are added? Longer startup times etc. etc.? I'm wondering what the balance between resource consumption and the number of enabled languages is. If there is no price to pay for enabled languages then enable them all by default - if it is consuming some resources then an option upon installation would make sense (with the hint that further languages can be enabled later on).

Actually an option upon installation to select the default language for the system would be cool in any case.

Also consider that there are propably lots of users who do not intend to run their system in more than one language at all, so they don't want to bother much with issues related to multiple languages I guess.

Collapse
Posted by Claudio Pasolini on
Internationalization is really great, but OpenACS startup has already become a complex and resources hungry affair. I vote as per Tilman suggestion: keep it an option at installation time, underlining further possibilities.
Collapse
Posted by Christian Eva on
I would also like to vote strongly for an additional installation page where we can click on the languages (from all available) which should be installed on the site. This could then become a site wide parameter set.

IMHO in practical terms there are not many sites (beside dotLRN demo installations) where all translations will be welcome as you want it to be consistent with your individual packages where you will not be able to translate all your messages into all the languages.

In my testing experience it makes quite a difference if you have 6 languages to load or all of them.

At this time I would like to give a big thanks to all the I18N team who did such a wonderful job!

Christian Eva

Collapse
Posted by Joel Aufrecht on
Collapse
Posted by Carl Robert Blesius on
Important: we only should include languages that are complete and/or someone is willing to stand behind (e.g. translation contacts for each language that are willing to stand up for a translation or at least make sure that suggestions for improvement are changed in the official translation). Having a whole bunch of "broken" translations installed by default and having no one around that can help fix them would not be a good thing.

I want acs-lang to have collaborative translation management infrastructure (didn't make it in this time around). It would be cool if users of acs-lang on distributed systems could suggest translation improvements by turning on the translation interface and clicking on a button which would then automatically submit a new translation and comment to a central system with built in translation workflow. Now that we have such solid translation infrastructure finding funding in the academic space to do this kind of thing should be easier (I hope). As we have more universities adopt .LRN maybe there will be translation departments that will help take this on.

Collapse
Posted by Malte Sussdorff on
Before anyone else has to look for ages, here is what I did to get it going:
  1. Go to /acs-lang/admin
  2. Enable the language you want to install by clicking on the checkbox
  3. Once enabled click on the label link
  4. You will see a link to import all messages for this locale. Click it and you are done
For sure it would be considerably more convenient if step 3 and 4 could be folded into step two.