Discussion:
[Openinteract-dev] Problem with localization keys and some localization gibberish
Teemu Arina
2004-07-29 18:17:04 UTC
Permalink
Hi,

OI 1.99_04 does not accept keys for localized messages that contain
something else other than dots and alphanumerals (for example, space does not
work).

OpenInteract2::I18N::Initializer
On line 138:
my ( $key, $msg ) = $line =~ /^\s*([\w\.]+)\s*=\s*(.*)$/;
Change to:
my ( $key, $msg ) = $line =~ /^\s*(\S.+\S)\s*=\s*(.*)$/;

.. because I prefer to have the actual english string as the key for easier
translation:
$self->_msg( "Operation failed: [_1]", $message );

Instead of something like:
$self->_msg( "example.failed", $message );

More readable. For very long chunks of text I still prefer to use the
translator unfriendly id key approach.

Also, current localization framework is very bad at UTF-8. As of my knowledge
Locale::Maketext is not multibyte safe. I'm also looking forward to a more
standard implementation of the localization message file format, i.e. GNU
gettext framework through Locale::Maketext::Gettext or
Locale::Maketext::Lexicon.

Implementation would require mapping bindtextdomain to packages locale/
directory (I would prefer that name instead of msg/), creating the directory
structure under locale/ to follow standards (e.g. en/LC_MESSAGES/myapp.mo),
using Locale::Maketext::* instead of Locale::Maketext and getting rid of the
home-grown .msg reader in I18N::Initializer. Support for setting the encoding
in package configuration would also be nice. gettext framework is multibyte
safe, so this would help in creation of a chinese translation, for example.

Extracting messages from perl source and creating the resulting PO files that
are Maketext compatible could be achieved easily with
Locale::Maketext::Extract and associated script xgettext.pl.

Btw., here is a a script for extracting strings from the selected .pm sources
and creating a file following the current format. It is not perfect. Expects
that $self->_msg() is used at all times:

---
#!/usr/bin/perl

foreach $file (@ARGV)
{
next unless -f $file;
open FILE, "< $file", or die "Can't open file $file: $!";
$out = undef;
while (<FILE>)
{
if ( /_msg\(.*?['"](.+?)['"]/ ) {
print $1 . " = " . $1 . "\n";
}
}
close FILE or die "Can't close file $file: $!";
}
---

Example use would be something like:
./extract_msg_strings OpenInteract2/Action/* | sort | uniq > msg/locale-en.msg

--
Teemu Arina
Dicole project
www.dicole.org
Teemu Arina
2004-07-31 12:54:01 UTC
Permalink
Post by Teemu Arina
OpenInteract2::I18N::Initializer
my ( $key, $msg ) = $line =~ /^\s*([\w\.]+)\s*=\s*(.*)$/;
my ( $key, $msg ) = $line =~ /^\s*(\S.+\S)\s*=\s*(.*)$/;
Well, I noticed that this breaks up if your key has a '=' character. Well,
sorry =) I might as well look at how to hack the PO support in which fixes
these sort of problems instead of trying to fix this home-grown message file
format too extensively.

Btw., if the key has a ' character (Like "I don't know"), it breaks up the
I18N::Initializer on line 221 (btw. nice use of TT for code generation here).
Change:
'[% msg_key %]' => qq{[% messages.$msg_key %]},
to:
qq{[% msg_key %]} => qq{[% messages.$msg_key %]},

Well, I wonder what happens if the message or the key has characters { or }...
;)

Btw., I thought about the PO support a while, it would be nice if the package
translation could be maintained as .po files under locale/ or something and
upon package installation the .po files are compiled as .mo and put into
usual places. Alternative option is to rely on the package maintainer to
provide both: po files for translators, compiled mo files for the
application.
Post by Teemu Arina
if ( /_msg\(.*?['"](.+?)['"]/ ) {
Well, this line in my script actually does not work if the string in your perl
code contains a character ' or ".. oobs.
--
--------------

Teemu Arina
Dicole project
http://www.dicole.org
Greg Fenton
2004-08-23 17:37:07 UTC
Permalink
So I'm fighting a losing battle on the corporate-politics front.

We are adopting a CMS for our corporate website (getting away from
static HTML). I want to build a system on top of OI/OI2. But I've
been stymied on a few fronts.

Is OI2 development stalled at this point? Is anyone building new apps
on top of OI2 yet?

If I can't get some footholds into OI2 within the next week or so, the
other team members will likely go to an "existing" OSS CMS (none of
which really meet our needs), a commercial CMS (none of which meet our
needs and will cost lots 'o $$$) or a .NET solution [meaning that I
walk away from the project altogether ;-) ]

Thanks in advance,
greg_fenton.

=====
Greg Fenton
***@yahoo.com




__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
Perrin Harkins
2004-08-23 17:42:21 UTC
Permalink
Post by Greg Fenton
If I can't get some footholds into OI2 within the next week or so, the
other team members will likely go to an "existing" OSS CMS (none of
which really meet our needs)
Depending on what your requirements are (workflow, permissions,
previewing, structured content entry, etc.), building a CMS from scratch
on OI2 might be a lot of work. If you're interested in a well-designed
and very flexible open source CMS in Perl, check out Krang:
http://krang.sf.net/

Krang is intended to be used for publishing your content to static
files, so you could still use OI2 for any dynamic parts of your site
without trouble.

- Perrin
Teemu Arina
2004-08-23 18:11:12 UTC
Permalink
Post by Greg Fenton
Is OI2 development stalled at this point? Is anyone building new apps
on top of OI2 yet?
Well, we have been building applications on top of OI1 and now OI2 for over a
year now and we are more than satisfied. Our latest work, soon to be released
is Dicole, http://www.dicole.org. We have extended the application framework
on top of OI2 for faster application development (the documentation is all on
the site, see developer documentation). For CMS, we prefer to integrate
something like the Mambo Open Source which is pretty good for a public
website and all other features will run under Dicole. Dicole has almost as
much source code as OI2, so you may imagine it is in fact a quite big
extension to OI2.

- Teemu

Loading...