A patch for rt-message-catalog to translate local/ stuff; usage added

RT Developers
1

Hi,
I have a wish please. It could be fine to have chance to use
localizations for customizations under local/ directory. That is
extracting strings from local/ tree and updating local/po/XX.po
lexicons. A patch for 3.8-trunk branch is attached. The patch also
solves to not overwrite local translations written into local/po/XX.po
while merging from Rosetta. The patch adds usage subroutine missing in
the rt-message-catalog.

I can do now:

rt2:/opt/RT# ./sbin/rt-message-catalog extract local/po/*.po
Looking at bin/mason_handler.svc
Looking at bin/webmux.pl
Looking at bin/rt-remind
…
Looking at etc/RT_SiteConfig.pm
Looking at etc/schema.mysql-4.1
Looking at etc/acl.Oracle
Looking at etc/schema.Sybase
Looking at etc/RT_Config.pm
Updating cs…

or

rt2:/opt/RT# sbin/rt-message-catalog rosetta /home/zito/migration/translation/ local/po/*.po
/home/zito/migration/translation//rt_rt-cs.po -> local/po/cs.po
Looking at bin/mason_handler.svc
Looking at bin/webmux.pl
Looking at bin/rt-remind
…
Looking at etc/schema.mysql-4.1
Looking at etc/acl.Oracle
Looking at etc/schema.Sybase
Looking at etc/RT_Config.pm
Updating cs…

Can someone review the patch please?
Best Regards
Zito

0001-usage-added-i18n-directory-parametrised.patch (4.47 KB)

2

It’s better to split usage part from other things. Move usage docs
into POD documentation and use Pod::Usage. Look into
sbin/rt-setup-database for example.

About main change. What would happen with plugins’ strings and po files?

Code looks good, however if I want to translate local customizations
then I want the following:

  • extract all strings
  • generate local po file prefering its values
  • shrink generated local po file so it contain only differences and
    strings that are no in main po file and plugins’ po files

As far as I can see you solve first and second things. The last one
would be cool to have as well.2011/3/16 Václav Ovsík vaclav.ovsik@i.cz:

Hi,
I have a wish please. It could be fine to have chance to use
localizations for customizations under local/ directory. That is
extracting strings from local/ tree and updating local/po/XX.po
lexicons. A patch for 3.8-trunk branch is attached. The patch also
solves to not overwrite local translations written into local/po/XX.po
while merging from Rosetta. The patch adds usage subroutine missing in
the rt-message-catalog.

I can do now:

rt2:/opt/RT# ./sbin/rt-message-catalog extract local/po/*.po
Looking at bin/mason_handler.svc
Looking at bin/webmux.pl
Looking at bin/rt-remind
…
Looking at etc/RT_SiteConfig.pm
Looking at etc/schema.mysql-4.1
Looking at etc/acl.Oracle
Looking at etc/schema.Sybase
Looking at etc/RT_Config.pm
Updating cs…

or

rt2:/opt/RT# sbin/rt-message-catalog rosetta /home/zito/migration/translation/ local/po/*.po
/home/zito/migration/translation//rt_rt-cs.po → local/po/cs.po
Looking at bin/mason_handler.svc
Looking at bin/webmux.pl
Looking at bin/rt-remind
…
Looking at etc/schema.mysql-4.1
Looking at etc/acl.Oracle
Looking at etc/schema.Sybase
Looking at etc/RT_Config.pm
Updating cs…

Can someone review the patch please?
Best Regards

Zito

List info: The rt-devel Archives

Best regards, Ruslan.

3

It’s better to split usage part from other things. Move usage docs
into POD documentation and use Pod::Usage. Look into
sbin/rt-setup-database for example.

Sounds reasonable. I have prepared this already…

About main change. What would happen with plugins’ strings and po files?

Code looks good, however if I want to translate local customizations
then I want the following:

  • extract all strings
  • generate local po file prefering its values
  • shrink generated local po file so it contain only differences and
    strings that are no in main po file and plugins’ po files

As far as I can see you solve first and second things. The last one
would be cool to have as well.

My notion was bad :(.
I lived with idea, that stuff under local/ (including po) overwrites
things from pure RT code.
I looked at RT::I18N::Init and things make more sense now. :slight_smile:
Thanks for the right direction Ruslan!

Should be scripts rt-message-catalog and extract-message-catalog kept
separate for some reason? Solving the above problem you described needs
probably addition some option switches controlling processing in both
scripts.

Thanks for your time.
Best Regards
Zito

4

It’s better to split usage part from other things. Move usage docs
into POD documentation and use Pod::Usage. Look into
sbin/rt-setup-database for example.

Sounds reasonable. I have prepared this already…

About main change. What would happen with plugins’ strings and po files?

Code looks good, however if I want to translate local customizations
then I want the following:

  • extract all strings
  • generate local po file prefering its values
  • shrink generated local po file so it contain only differences and
    strings that are no in main po file and plugins’ po files

As far as I can see you solve first and second things. The last one
would be cool to have as well.

My notion was bad :(.
I lived with idea, that stuff under local/ (including po) overwrites
things from pure RT code.

They do, but also override plugins’.

I looked at RT::I18N::Init and things make more sense now. :slight_smile:
Thanks for the right direction Ruslan!

Should be scripts rt-message-catalog and extract-message-catalog kept
separate for some reason? Solving the above problem you described needs
probably addition some option switches controlling processing in both
scripts.

See no problems in adding arguments into extract-message-catalog,
passing arguments from rt-message-catalog when extract called. I
really don’t know why those are splitted.

I think what we need a command in rt-message-catalog that creates a
local po file that does the following:

  1. extracts strings from files in local/, but skips plugins
  2. updates local .po file if it already exists
  3. uses API to extract dynamic strings with lifecycle we get bunch and
    will have more in the future
  4. has option to bring every string
  5. has option to bring not translated strings

As bonus shrink command or a new one should be able to shrink local po
file to its minimal variant.

Will it do the job for you?

Thanks for your time.
Best Regards

Zito

Best regards, Ruslan.

5

Hi Ruslan,

…
See no problems in adding arguments into extract-message-catalog,
passing arguments from rt-message-catalog when extract called. I
really don’t know why those are splitted.

I did some work on github.com:zito/rt branch 3.8-trunk.

I moved the code from the extract-message-catalog into the
rt-message-catalog, the script extract-message-catalog replaced with
symlink to rt-message-catalog. Calling rt-message-catalog extract… and
extract-message-catalog… is equivalent now as before.
No need to duplicate options parsing.

I think what we need a command in rt-message-catalog that creates a
local po file that does the following:

  1. extracts strings from files in local/, but skips plugins
    done, passing --local option to extract command will do this job
  1. updates local .po file if it already exists
    done
  1. uses API to extract dynamic strings with lifecycle we get bunch and
    will have more in the future
  2. has option to bring every string
  3. has option to bring not translated strings
    Sorry, I don’t understand this items.

As bonus shrink command or a new one should be able to shrink local po
file to its minimal variant.

Option --exclude-from added to the shrink command, so it excludes
strings from other po archives with the same name but other locations.
Extract with --local option calls shrink with options
–exclude-from lib/RT/I18N --exclude-from local/plugins/*/po
so the messages from core RT code and from plugins are excluded.

Will it do the job for you?

I hope it does. I tried to restart RT and see translated local strings
and a local cs.po archive is a fraction of previous. Thanks.

I hope my mods are useful for implementing the described functionality
into the common RT code.

Best Regards
Zito