Menu
▾
▴
openinteract-help
|
From: Salve N. <sal...@me...> - 2004-02-13 13:37:15
|
Hi! We're considering on using OpenInteract as a CMS at my workplace, mostly because of SPOPS and the plugin architecture (and the fact that OI is quite cool :) But some of my colleagues are a bit apprehensive about there not being any updates since september... Is there a reason to be nervous? Are there any new (1.x or 2.x) releases in the pipeline? Any lifesign would be very much appreciated. :) kind regards, - Salve J. Nilsen -- Salve J. Nilsen <sa...@me...>, Systems Developer met.no, IT-department, Section Development |
|
From: Chris W. <ch...@cw...> - 2004-02-13 15:55:22
|
On Feb 13, 2004, at 8:35 AM, Salve Nilsen wrote: > We're considering on using OpenInteract as a CMS at my workplace, > mostly because of SPOPS and the plugin architecture (and the fact that > OI is quite cool :) > > But some of my colleagues are a bit apprehensive about there not being > any updates since september... Is there a reason to be nervous? Are > there any new (1.x or 2.x) releases in the pipeline? > > Any lifesign would be very much appreciated. :) The 1.x branch is fairly stable and will generally only get bugfixes from now on. The 2.x branch is under active development (with periodic pauses) and the next beta/release-candidate should be out in a week or two. (Honest!) It includes quite a few changes from the previous beta, including internationalization support plus lots of stuff under the hood. If you're just starting out with a project I strongly recommend using 2.0. It has much better documentation and architecture than 1.x. It also runs under more environments, not just Apache 1.x. More soon.... Chris -- Chris Winters Creating enterprise-capable snack systems since 1988 |
|
From: Andreas N. <an...@kl...> - 2004-02-13 16:16:21
|
On Fri, 2004-02-13 at 14:35, Salve Nilsen wrote: > Hi! > > We're considering on using OpenInteract as a CMS at my workplace, mostly > because of SPOPS and the plugin architecture (and the fact that OI is > quite cool :) - sounds familiar > > But some of my colleagues are a bit apprehensive about there not being > any updates since september... Is there a reason to be nervous? Are > there any new (1.x or 2.x) releases in the pipeline? 1.x is only being maintained to fix bugs, but will probably not get any new featurs. You still can expect help from the mailing lists. Our company ( arvato direct services ) chose OI 1 two years ago as out platform of choice for our intranet applications, currently running with about 1000 clients, and also some end user internet sites. We still invest heavily into that architecture in the near future ( software for call centers, workflow systems, etc.). >From that experience I can tell you, that OI 1 is a production class system already and I currently do not know of any bugs. 2.x is still being actively developed, but in the end of last year we distracted Chris Winters mind a bit towards a new area, which he put quite some effort in. I expect him too release the first live signs of that project soon, which will of course integrate nicely with OI. ( Hint: it will be all about Workflows in Perl... ) To my knowledge, Chris is currently extremely busy in his day job, leaving not as much time for OI. Having met him in person though, I would always bet on him going on with OI 2 soon. Also, OI 2 is already running smooth. If you think about production usage, though - you got to go for OI 1 now. If you wrap your application logic around SPOPS, then it should not be too hard to port you app later to OI 2.x . > > Any lifesign would be very much appreciated. :) ping ;-) serious: I really believe that OI is currently the best plattform for developing web applications with Perl. Do you have any specific questions yet ? later, Andreas |
|
From: Jim H. <ja...@tr...> - 2004-02-13 17:05:58
|
> But some of my colleagues are a bit apprehensive about there > not being any updates since september... Is there a reason > to be nervous? Are there any new (1.x or 2.x) releases in the pipeline? I have to admit I was a bit nervous when openinteract.org/com went away, as we have been using OI in production for almost 2 or 3 years now. But then I subscribed to the commits mailing list and indeed saw Good Mr. Winters committing code just last night. We're very much looking forward to OI2 which we will celebrate with a big refactoring of our own code and new server hardware. -Jim |
|
From: Chris W. <ch...@cw...> - 2004-02-13 18:46:10
|
On Feb 13, 2004, at 12:03 PM, Jim Howard wrote: >> But some of my colleagues are a bit apprehensive about there >> not being any updates since september... Is there a reason >> to be nervous? Are there any new (1.x or 2.x) releases in the >> pipeline? > > I have to admit I was a bit nervous when openinteract.org/com went > away, as > we have been using OI in production for almost 2 or 3 years now. Sorry about that. The company where it's hosted is having some problems maintaining it. That has *zero* effect on the state of OI, but I realize that appearances are very important. I hope to get all the OI stuff onto one of my own servers in the next few months -- I have someone who will do the hosting for me, but I need to buy a rackmount server and get it loaded up. The "buy" part of that statement is the only holdup now :-) > We're very much looking forward to OI2 which we will celebrate with a > big > refactoring of our own code and new server hardware. It would be great if when you're doing that you keep track of what tripped you up (or worked really well!) so we can feed that back into the docs. Chris -- Chris Winters Creating enterprise-capable snack systems since 1988 |
|
From: Teemu A. <te...@io...> - 2004-02-13 19:25:42
|
> serious: I really believe that OI is currently the best plattform for > developing web applications with Perl. I agree. I tried several platforms (for example, Mason) after moving to OI. I personally like the quality of the code and available documentation produced for OI in top of the basic features that do everything smoothly what I need for a web application server. I also checked Zope out but I didn't like the ammount of features they have put into it, resulting in a quite of a learning curve to know how to do things the correct way. I also find OI very lightweight and SPOPS very effective in performance. I call it "Zope without the bloat" =) The only lack in OI I find is easy creation of content without the need to create templates (I call them Fields) and also the possibility to build Validators (basic user input validation for the fields. For example a number based field for age should only contain numbers) and Constructors (converting abstract Field types to something like HTML based fields or something else). In plone they have Archetypes (formerly CMFTyles) for such and in some other languages like Java I think they call them FieldEditors. Earlier on this list I told I'm working on such an higher level platform based on OI and the alpha sources are already available and it sure reduces the development time of web applications. Based on my efforts I have worked this week on a File Manager that features tree view, icon view and detailed view of files with meta-data. Some nice features include cut/copy/paste files and downloading selected files and directories as Zip or Tar/gz and also uncompressing such files in the server side. For Chris, I would like to hear more about the final details how internationalization is going to be implemented in the next release, before I start to work on my own =) -- Best regards, Teemu Arina Ionstream Oy / Dicole Komeetankuja 4 A 02210 Espoo FINLAND Tel: +358-(0)50 - 555 7636 http://www.mimerdesk.org http://www.dicole.fi/en |
|
From: Chris W. <ch...@cw...> - 2004-02-13 22:17:08
|
On Feb 13, 2004, at 2:15 PM, Teemu Arina wrote: > ... > For Chris, I would like to hear more about the final details how > internationalization is going to be implemented in the next release, > before I > start to work on my own =) I just posted updated docs to the SF site. http://openinteract.sourceforge.net/docs/oi2-snapshot/ In particular you want to read: http://openinteract.sourceforge.net/docs/oi2-snapshot/OpenInteract2/ Manual/I18N.shtml The thirty-second version: - We're using Locale::Maketext for everything - Every package can define a set of message files (normally in msg/); these use a slightly modified Java message bundle syntax (easy to write!) - All message files for all languages get read in at server startup and classes for Locale::Maketext generated from them - On every request OI determines what language you're using (customizable, of course) I don't have the template interaction there yet -- basically, TT2 will have two global functions in your template namespace: # Grab a message from the correct message bundle using # $message_key and interpolating any arguments as # necessary MSG( $message_key, [ arg1, arg2, ... ] ) # Return a Locale::Maketext handle LH() Programmatically you grab a Locale::Maketext handle from the request object: my $lh = CTX->request->language_handle; Let me know if you have any ideas/features/improvements in this area. I've tried to make it as easy as possible to ship localized applications by allowing the packages to define their own messages. And retrieving the messages is I think also pretty simple. I'm in the middle of creating english localization files all the packages shipped with OI2. Talk about a boring job... :-) Later, Chris -- Chris Winters Creating enterprise-capable snack systems since 1988 |
|
From: Teemu A. <te...@io...> - 2004-02-13 23:41:27
|
> - We're using Locale::Maketext for everything > - Every package can define a set of message files (normally in msg/); I used to work for a project that had 20 translations. We first used opaque IDs for identifying the strings. We soon noticed it was hard to translate, because once you translated the string from english to some other language, you don't see the original english string anywhere unless you put it in comments or look for it in the orginial english translation file. My question for opaque IDs is: how do you easily improve a translation if the keys are not based on the base language (comparing original to current, making modifications...)? Another thing was the self-documenting aspects of having the base language key in the code. Consider for example: $lh->maketext( 'Hello [_1], today is [_2]', $username, $date ); vs: $lh->maketext( 'desktop.welcome', $username, $date ); If you are first time reading the code, it's not always obvious what that peace of code will actually produce unless you search the translation file at the same time. Now another point: It is very common that some projects just never have 100% complete translations and it is common that translation files lacking latest improvements have some required keys missing. In that case I would suggest the logic: 1. look for requested key from the requested translation (e.g. spanish) 2. If not found, look for requested key from the default translation (english) 3. If not found, produce error This way you can still use 100% translations that are made for some older versions, although some strings might appear in english. If you consider using base language as keys, consider working around the global key problem (if I understood correctly, the keys have to be unique, even over package boundaries). For example, Maketext objects could be initialized for each package, so that the key name-space is unique for every package. Very useful, in my opinion.. you never know what strings or keys some other project will use. > these use a slightly modified Java message bundle syntax (easy to > write!) In my opinion you should use gettext (PO files), because there are easy translation project management tools available for programs using gettext. I for example find Kbabel brilliant for that job: http://i18n.kde.org/tools/kbabel/ This tool for example hides the syntax details (editing hand results very often in syntax errors, even if the file is easy to edit), resulting in perfectly formatted files. This tool also tells you statistics of each translation: how many strings translated, how many % translated, how many fuzzy strings you have (.po format has this nice # ,fuzzy thing, which enables you to mark certain translation as "being under consideration".. imagine translating from english to chinese.. the translation is not always obvious). Also, easy navigation like "next untranslated string" helps a lot when you get into a mood of translating, when you don't have to look for untranslated or fuzzy translations by eye. Built-in spell checking (!) and dictionary-helper also helps maintaining basic quality of the translation. Syntax highlight etc.. Also, many translators are not techies. Even a simple file could be hard to modify by hand and remember all the syntax. Believe me, the small learning curve could affect their willing to try the translation process at all. There are also a plenty of graphical translation tools available for Windows and Unix that support the gettext system. > I'm in the middle of creating english localization files all the > packages shipped with OI2. Talk about a boring job... :-) Another point why to use base language strings as keys here: you could easily write a script that goes through your script, extracts strings from commands like $lh->maketext( 'Hello [_1], today is [_2]', $username, $weekday ) and generate a translation file for you. This way you could just improve the english translation in your code and then generate an up to date version of the translation file. In your FAQ you state: "if you change the key in the base language even for punctuation you'll need to change all of them" I solved this problem by writing a script that compared old and new strings and replaced them in the translation files. No more doing it by hand. I also wrote a script that compared each foreign translation to the base translation and added missing translation keys from base translation to foreign translation files and also produced a warning if foreign translation files contained keys not present in base translation (very common if you typo things or remove old keys form base translation). Also, gnu gettext utils also contain some really useful tools for development like msgfmt. It is helpful for checking translation file syntax, produce some statistics etc. msgcmp compares two .po files finding differencies like missing msgid strings. Hope this helps, Teemu Arina Ionstream Oy / Dicole Komeetankuja 4 A 02210 Espoo FINLAND Tel: +358-(0)50 - 555 7636 http://www.mimerdesk.org http://www.dicole.fi/en |
|
From: Chris W. <ch...@cw...> - 2004-02-14 01:07:26
|
On Feb 13, 2004, at 6:30 PM, Teemu Arina wrote: > I used to work for a project that had 20 translations. We first used > opaque > IDs for identifying the strings. We soon noticed it was hard to > translate, > because once you translated the string from english to some other > language, ... You've given me a lot to think about. Thanks a lot for the ideas and experience. Even if it means maybe undoing some work... :-) More soon... Chris -- Chris Winters Creating enterprise-capable snack systems since 1988 |
|
From: Chris W. <ch...@cw...> - 2004-02-14 18:01:22
|
Okay, I've thought about this a little bit. Keep in mind that I'm still
open to different approaches as you read this, and the rambling nature
of the email reflects it. (Lots of thinking out loud...)
On Feb 13, 2004, at 6:30 PM, Teemu Arina wrote:
...
> because once you translated the string from english to some other
> language,
> you don't see the original english string anywhere unless you put it in
> comments or look for it in the orginial english translation file. My
> question
> for opaque IDs is: how do you easily improve a translation if the keys
> are
> not based on the base language (comparing original to current, making
> modifications...)?
>
> Another thing was the self-documenting aspects of having the base
> language key
> in the code. Consider for example:
>
> $lh->maketext( 'Hello [_1], today is [_2]', $username, $date );
>
> vs:
>
> $lh->maketext( 'desktop.welcome', $username, $date );
I agree with your points, but my three main objections to using the
base language as the key are:
* What do you do with long strings? (One or more sentences)
* What happens when you change the base language text?
* Many of the base language keys will be quite long.
For the first objection I guess you could just use the first part of it
the long string. This kind of eliminates the benefit of using the base
language as key, it's not used as often.
The second objection seems like a big problem. How often does it
happen? Not sure. But like I mention in the manual doc it seems very
brittle. (Using your suggestion from later in the email -- syncing
things up with a script -- seems like an interesting idea. But still
work...)
The third one seems like it would be very annoying for authors. You
have more experience with this, granted. I'm really trying to make it
easy to do the right thing for people who want to distribute their
applications.
> Now another point: It is very common that some projects just never
> have 100%
> complete translations and it is common that translation files lacking
> latest
> improvements have some required keys missing. In that case I would
> suggest
> the logic:
>
> 1. look for requested key from the requested translation (e.g. spanish)
> 2. If not found, look for requested key from the default translation
> (english)
> 3. If not found, produce error
Locale::Maketext takes care of this. In fact it will do language
differentiation (or whatever the term is) as well. For instance if I'm
creating customizations for Mexican Spanish I can create a file:
mymessages-es_mx.msg
Any messages not found there will look in:
mymessages-es.msg
And any messages not found there will look in the default language,
which is normally English:
mymessages-en.msg
But you can also present to L::M a series of languages to try out. OI2
will pull the browser preferences ('Accept-Language' header) if they're
available so if your preference is Spanish then Portuguese it will try
those before the default.
> If you consider using base language as keys, consider working around
> the
> global key problem (if I understood correctly, the keys have to be
> unique,
> even over package boundaries). For example, Maketext objects could be
> initialized for each package, so that the key name-space is unique for
> every
> package. Very useful, in my opinion.. you never know what strings or
> keys
> some other project will use.
This is true but... (thinking out loud here)
Well, my initial impression is that this is getting too complicated.
But perhaps not. If we think of a package as a distributable
application then there's really no reason that a package would use the
keys of another package, right? In fact we could probably assume that
the only other keys a package needs are some global keys for text used
all over the place (standard button text, copyright, disclaimers,
etc.).
Okay, I think I could go along with this. I would like the option of
putting a package's keys in the global namespace for applications using
multiple packages. But the default should be that when requesting a
message key you only look in your package's space and the global space
if it's not found there.
The only tricky part with this is now we have to let OI2 know what
package we're currently in. This isn't so hard for templates or even
actions. But normal perl classes will probably be more difficult --
that is, if I want to emit an error message from my class
OpenInteract2::User:
return $lh->maketext( 'error.password_mismatch' );
Then how will OI know to look into the OI2::I18N::base_user package for
the key? ... Maybe at server startup we can do a mapping of all keys to
the package they were read from and in cases of ambiguity refer to it.
We can also create a wrapper for the maketext call that would allow
another parameter to nail down the right package. (This wrapper idea
might come in handy to use different message storage schemes, more
below...)
>> these use a slightly modified Java message bundle syntax (easy to
>> write!)
>
> In my opinion you should use gettext (PO files), because there are easy
> translation project management tools available for programs using
> gettext.
> I for example find Kbabel brilliant for that job:
> http://i18n.kde.org/tools/kbabel/
... (lots more interesting stuff about kbabel clipped)
This is a good idea -- I would like to make it possible to use tools
like this. But I don't want to get rid of the benefits of using
plaintext files as well.
After a little investigation it looks like the
Locale::Maketext::Lexicon module (from another superhero, Autrijus)
solves this problem for us. (Hooray for CPAN!) It seems to allow you to
read in .po/.mo files for the Locale::Maketext lexicon. It also looks
like it would be no problem to adapt it to our OI2::I18N::mypackage
naming scheme from above. (That is, keeping every package separate.) It
seems to even translate the gettext functions %1 %2 to [_1] [_2] used
by maketext. Sweet!
> Another point why to use base language strings as keys here: you could
> easily
> write a script that goes through your script, extracts strings from
> commands
> like $lh->maketext( 'Hello [_1], today is [_2]', $username, $weekday )
> and
> generate a translation file for you. This way you could just improve
> the
> english translation in your code and then generate an up to date
> version of
> the translation file.
True, but I think most uses of the messages will be in templates where
it's much more difficult to parse groups of text out into individual
entries.
> Also, gnu gettext utils also contain some really useful tools for
> development
> like msgfmt. It is helpful for checking translation file syntax,
> produce some
> statistics etc. msgcmp compares two .po files finding differencies like
> missing msgid strings.
Very useful.
> Hope this helps,
Immensely. Thanks for the great ideas and time it took to put them
together.
Chris
--
Chris Winters
Creating enterprise-capable snack systems since 1988
|
|
From: Chris W. <ch...@cw...> - 2004-02-14 18:05:41
|
On Feb 13, 2004, at 6:30 PM, Teemu Arina wrote: ... > I for example find Kbabel brilliant for that job: > http://i18n.kde.org/tools/kbabel/ Along with this discussion, I think it would be a good idea to include a 'translate' package with OI2 that allows web-based editing of the translation files. It might not be as slick as kbabel, but it will always be there and will hopefully take care of the most common tasks. What do you think? Chris -- Chris Winters Creating enterprise-capable snack systems since 1988 |
|
From: Teemu A. <te...@io...> - 2004-02-16 13:44:50
|
> Along with this discussion, I think it would be a good idea to include > a 'translate' package with OI2 that allows web-based editing of the > translation files. It might not be as slick as kbabel, but it will > always be there and will hopefully take care of the most common tasks. Great idea. I think that would make the translation process very easy. A new translator could start immediatly still while the interest lasts. ...and doesn't even require downloading the sources or anything. I was also thinking how one could translate programs while using it but technically implementing it might be too much of work. Translation process usually requires the translator to see the context in order to come up with a correct translation. - Teemu |
|
From: Chris W. <ch...@cw...> - 2004-02-16 16:01:45
|
On Feb 16, 2004, at 8:31 AM, Teemu Arina wrote: >> Along with this discussion, I think it would be a good idea to include >> a 'translate' package with OI2 that allows web-based editing of the >> translation files. It might not be as slick as kbabel, but it will >> always be there and will hopefully take care of the most common tasks. > > Great idea. I think that would make the translation process very easy. > A new > translator could start immediatly still while the interest lasts. > ...and > doesn't even require downloading the sources or anything. Right. Plus they could do it from anywhere. > I was also thinking how one could translate programs while using it but > technically implementing it might be too much of work. Translation > process > usually requires the translator to see the context in order to come up > with a > correct translation. It's a small implementation detail, but one thing I planned on doing: create a new logging category 'OI2.TRANSLATE'. If set to 'DEBUG' then with every message printed out we prepend the message key. So when you ask for: MSG( 'user.welcome', user.full_name ) You get something like: [user.welcome] Welcome to my website Chris Winters! or even to be more explicit where the boundaries are: [user.welcome Welcome to my website Chris Winters!] Chris -- Chris Winters Creating enterprise-capable snack systems since 1988 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X