RE: Strings db (comments requested)
Hi Grant,
Just as a suggestion, i would use the PO format (already used by other tools
than gettext, like KDE) so we get for free all the catalog manager tools
(like Kbabel, which is very nice, by the way).
And maybe error codes output could be just another target language. So:
fprintf(stderr, i18n ("Error #43: Can't stat file\n") )
Prints just "ERR43\n" when language var is set to, say, "CODES".
--
Angel Faus
Director Técnico
vLex.com
-
[EMAIL PROTECTED]
RE: Strings db (comments requested)
Here's the situation (as I understand it): Parrot needs to stop emitting strings exclusively in English. Parrot needs a standard file format for a string replacement db. Parrot should only put strings to stderr (except when told to). Parrot should be able to emit "error IDs" instead of strings. Parrot presently has about 200 strings that are targets. Here's what I propose: A standard library that allows loading of a strings db at run-time based upon a defined order of variable testing. This might mean that the library would getenv a variable, then check for a command-line option, then check for the default Parrot value. A string database that has number/value pairs, where the number corresponds to the error number defined by Parrot, and the value is the string to emit for that number. A configure directive that tells the library to emit only error numbers only (no strings). This would then allow any language built on top of Parrot to intercept these codes for it's own purpose without having to parse a string. A tool for managing the strings db. This would need to include adherence to some sort of yet-undefined standard of assigning error codes. Perhaps using SOAP? a socket connection to CPAN? Any ideas are welcome. Bibliography: http://dev.perl.org/rfc/85.pod - RFC 85 http://dev.perl.org/rfc/296.pod - RFC 296 http://dev.perl.org/rfc/313.pod - RFC 313 Please comment. Grant M. [EMAIL PROTECTED]
RE: Strings db
Damien Neil [mailto:[EMAIL PROTECTED]] wrote: > This is a far more error-prone interface in a number of ways > (...) I don't believe that with the proper tools and rules that this system will be any more difficult to manage. All of the things that you stated as disadvantages could be countered with similar disadvantages with using strings as keys. I will note that I could see using strings that look like constants for keys, where "THREAD_EXCEPTION" is the key for the string lookup (that's if it's deemed that this is beneficial in some way). > (...) > (If there is one thing that Perl > has demonstrated, it is that looking up a string in a hash is fast.) This isn't Perl, but Parrot (written in C), and if I understand it correctly, that's all that this mechanism is for. Perl (and any other language built on top of Parrot) will need to implement it's own strategy for dealing with i18n/l10n. I suspect that Parrot will want to keep stdout/stderr output to a minimum, as it's really the language implemented on top of Parrot that should be catching the majority of errors. I'd still like to hear some input from someone who's used any similar system (gettext or other). I have, but it was in Tcl, and in Tcl "the string's the thing" (but the system did use 'pseudo'-constants as the keys). Grant M. [EMAIL PROTECTED] P.S.> I'm not dead-set against using strings, I just want to see that we do the right thing.
Re: Strings db
On Tue, Sep 25, 2001 at 07:29:01PM -0700, Wizard wrote: > Actually, the thing that I didn't like was using an actual string as the > message_id. I would have expected something more in the way of: > > char *err = get_text_string( THREAD_EXCEPTION_117, \ > "THREAD EXCEPTION: Not enough handles." ); This is a far more error-prone interface in a number of ways: It is very easy for the mapping between the number and the string to be lost. Adding and removing strings is harder: the string list will become filled with holes (or must be renumbered), and the numeric order of the strings will probably not correspond with the logical order. Numerically indexes are far more prone to failure when using out-of-date catalog files, while string-indexed ones will mostly continue to work. (With the obvious exception that messages not contained in the old catalog cannot be displayed from it.) All these disadvantages are a significant penalty to pay for a very minor improvement in efficiency. (If there is one thing that Perl has demonstrated, it is that looking up a string in a hash is fast.) - Damien
RE: Strings db
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] wrote:
> You quoted something similar to my text above and said you didn't
> like it. I
> believe mostly because it involved reading external files, but
> also because of
> the concept of the message-id.
Actually, the thing that I didn't like was using an actual string as the
message_id. I would have expected something more in the way of:
char *err = get_text_string( THREAD_EXCEPTION_117, \
"THREAD EXCEPTION: Not enough handles." );
where "THREAD_EXCEPTION_117" is defined as:
#define THREAD_EXCEPTION_117 117
and the actual catalog values are defined as an array ("strings[117]"),
either build-time or run-time, from a language file (such as
"./strings/lang.en"). The second string is a 'fallback' string that is
displayed if the value doesn't exist or exists as NULL (and to aid
readability). It just felt weird to me to use the actual string for the
message id.
> I realize that you were merely inciting that we should be able to develop
> something, I was just commenting on performance.
I'm not sure where performance is affected with either scenario, as both
systems could be made to work in a similar manner behind the scene.
Grant M.
Re: Strings db
Wizard wrote: > Michael Maraist [mailto:[EMAIL PROTECTED]] wrote: > > Does you idea allow for: > > int msgid = txtToMsgid( "This feels strange\n" ); > > char *label = msgidToRes( msgid ); > > I'm not sure that I understand your question. This is not my idea, but GNU's > gettext tools. I, myself, am not thrilled with this implementation, and > would suggest using some other implementation (either our own or someone > else's). > Grant M. You quoted something similar to my text above and said you didn't like it. I believe mostly because it involved reading external files, but also because of the concept of the message-id. My statement was that there are efficient reasons to want to use a message-id, so it should be possible to have two api's, one with and one that's direct (which is simply a wrapper around the former). I realize that you were merely inciting that we should be able to develop something, I was just commenting on performance. -Michael
RE: Strings db
Michael Maraist [mailto:[EMAIL PROTECTED]] wrote: > ... but I'm assuming it involves (among other things) displaying > locale-based error messages. I'm not sure how the catalog would be determined, but I would suggest another mechanism other than locale. Rather, I'd suggest a user-specific environment variable or config file. Grant M. [EMAIL PROTECTED]
RE: Strings db
Michael Maraist [mailto:[EMAIL PROTECTED]] wrote: > Does you idea allow for: > int msgid = txtToMsgid( "This feels strange\n" ); > char *label = msgidToRes( msgid ); I'm not sure that I understand your question. This is not my idea, but GNU's gettext tools. I, myself, am not thrilled with this implementation, and would suggest using some other implementation (either our own or someone else's). Grant M.
RE: Strings db
> and a call to the API would be: > char *label = gettext( "This feels strange\n" ); Does you idea allow for: int msgid = txtToMsgid( "This feels strange\n" ); char *label = msgidToRes( msgid ); In addition to the above, since this affords compile-time optimizations? I'm not following this thread with enthusiasm (I'm an English Biggot myself), but I'm assuming it involves (among other things) displaying locale-based error messages. Such messages could be known after compilation. Granted errors don't really need to be fail-fast. -Michael
RE: Strings db
I've been looking over the gettext implementation, and I'm not sure that I entirely like it, but let me know if this sounds like I've been programming to long. (Maybe I'm misreading the document) The gettext API uses strings as "msgid". What this means is that in order to get a translated string, you might make a call like this: char *err = gettext( "Can't mmap, code!\n" ); There would then need to be an entry in the "PO" file with a msgid that matches this string. Does this sound strange? Not to sound like I'm set in my ways, or anything (but I am ;-), but I myself would expect msgid to be a #define'd numeric value. Here's a condensed example of a gettext PO entry: ... msgid "This feels strange\n" (this would be used in the gettext call) msgstr "This feels weird\n" (this line would be what's returned) and a call to the API would be: char *label = gettext( "This feels strange\n" ); Sorry, but it just seems weird to me. Couldn't we do a better job of implementing this, as well as creating a conversion system to convert PO files to our format? We would not however, be compatible with the API. Is this a bad thing? Let me know if it's just me, Grant M.
RE: Strings db
> > GNU does offer the gettext tools library for just such a purpose. I don't > > know how it will translate to the various platforms however, and it likely > > is a major overkill for what we are trying to do. > > http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose > > It might make sense to implement something like this now, rather than create > > our own system and find out it is insufficient down the road. > > Just a thought, > > Grant M. > > But wouldn't that make parrot GPL'd? You could use the gettext tools to generate the catalogs, and reimplement the part that reads the strings from the catalog. wxWindows does just that. Regards Mattia
Re: Strings db
At 08:42 PM 9/24/2001 +0200, Paolo Molaro wrote: >On 09/24/01 Michael Maraist wrote: > > > GNU does offer the gettext tools library for just such a purpose. I don't > > > know how it will translate to the various platforms however, and it > likely > > > is a major overkill for what we are trying to do. > > > http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose > > > It might make sense to implement something like this now, rather than > create > > > our own system and find out it is insufficient down the road. > > > Just a thought, > > > Grant M. > > > > But wouldn't that make parrot GPL'd? > >IIRC, the latest release is LGPL and GLib 2.0 will probably contain a >(again LGPL) gettext implementation to be used on systems that don't >provide their own. LGPL's much better, though we still have the issue of portability and self-containedness. We'd probably end up having to ship gettext with perl, which has its own set of problems. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Strings db
On 09/24/01 Michael Maraist wrote: > > GNU does offer the gettext tools library for just such a purpose. I don't > > know how it will translate to the various platforms however, and it likely > > is a major overkill for what we are trying to do. > > http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose > > It might make sense to implement something like this now, rather than create > > our own system and find out it is insufficient down the road. > > Just a thought, > > Grant M. > > But wouldn't that make parrot GPL'd? IIRC, the latest release is LGPL and GLib 2.0 will probably contain a (again LGPL) gettext implementation to be used on systems that don't provide their own. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
RE: Strings db
At 12:38 PM 9/24/2001 -0400, Michael Maraist wrote: > > GNU does offer the gettext tools library for just such a purpose. I don't > > know how it will translate to the various platforms however, and it likely > > is a major overkill for what we are trying to do. > > http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose > > It might make sense to implement something like this now, rather than > create > > our own system and find out it is insufficient down the road. > > Just a thought, > > Grant M. > >But wouldn't that make parrot GPL'd? Not if we re-implemented it. Which wouldn't be unreasonable if the interface is good. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Strings db
We could use the bsd gettext though, couldn't we? --Josh At 12:49 on 09/24/2001 PDT, "Wizard" <[EMAIL PROTECTED]> wrote: > Michael Maraist wrote: > > But wouldn't that make parrot GPL'd? > Yes, Yes it would. > (cup o' coffee and a sux donut, please.) > Never mind. I'll take a look at the docs and look around some more and see > what other clever ideas we can't use. > Grant M. > >
RE: Strings db
Michael Maraist wrote: > But wouldn't that make parrot GPL'd? Yes, Yes it would. (cup o' coffee and a sux donut, please.) Never mind. I'll take a look at the docs and look around some more and see what other clever ideas we can't use. Grant M.
RE: Strings db
> GNU does offer the gettext tools library for just such a purpose. I don't > know how it will translate to the various platforms however, and it likely > is a major overkill for what we are trying to do. > http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose > It might make sense to implement something like this now, rather than create > our own system and find out it is insufficient down the road. > Just a thought, > Grant M. But wouldn't that make parrot GPL'd? -Michael
RE: Strings db
GNU does offer the gettext tools library for just such a purpose. I don't know how it will translate to the various platforms however, and it likely is a major overkill for what we are trying to do. http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose It might make sense to implement something like this now, rather than create our own system and find out it is insufficient down the road. Just a thought, Grant M.
RE: Strings db
At 09:42 AM 9/24/2001 -0700, Wizard wrote: >Some questions about implementation: >which scenarios?: >1.> external text-file strings (name=value?) chosen at run-time >2.> Parrot build-time embedded strings (language chosen at configure) > >Do we want to break the messages into sets, such that <256 is 'fatal', 256 >to 511 is 'warning', 512 to 767 is 'informational', and 768 to 1023 is 'UI'? I'd rather choose low bits for the general status. (And my tendency is to snag the VMS standard, as its as good as anything else) As for the rest, it really beats me--I have close to zero experience in the area, so I'm not comfortable making a declaration. I'd assume the best thing to do is hand off an error code and parameters, and the I18N stuff looks up the appropriate error message from the local catalog (probably set at perl compile time or via an ENV entry or system locale or something) and spits out a formatted error. I'd love it if someone with more I18N experience than me would draft up a proposal, even if it's "We should do what ZZZ does, which is..." Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Strings db
Some questions about implementation: which scenarios?: 1.> external text-file strings (name=value?) chosen at run-time 2.> Parrot build-time embedded strings (language chosen at configure) Do we want to break the messages into sets, such that <256 is 'fatal', 256 to 511 is 'warning', 512 to 767 is 'informational', and 768 to 1023 is 'UI'? I remember somewhere where each user could specify their list of preferred languages in descending order (i.e., "en; fr; de; ..."), and the application would choose based upon available string files (a .parrc file?), defaulting back to the build-time language. Is this something that makes sense at this level, or should we just ask the user to specify an ENV variable? Is there a better way? Also, do we want to embed sprintf formatting in the strings, or should that be appended data? Perhaps some standardization of all error strings to be something on the order of: void perror(int error_id, char *val_1_name, char *val_1, \ char *val_2_name, char *val_2, ... ) which would print to stderr like so: error_id: (char *)string_lookup(error_id)\n *val_1_name: *val_1\n *val_2_name: *val_2\n ... make sense? Grant M.
Re: Strings db
At 01:32 AM 9/24/2001 +0100, Simon Cozens wrote: >On Sun, Sep 23, 2001 at 08:42:51PM -0700, Wizard wrote: > > Is Parrot to have a strings db for error and UI strings (i18n)? > >Parrot should not be outputting that many errors or UI strings. However, >those that it does should go through I18N, yes. So, does anyone want to take a shot at some sort of library routines to handle I18N for the error code? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Strings db
On Sun, Sep 23, 2001 at 08:42:51PM -0700, Wizard wrote: > Is Parrot to have a strings db for error and UI strings (i18n)? Parrot should not be outputting that many errors or UI strings. However, those that it does should go through I18N, yes. > If so, it should probably go on the TODO list (the sooner the better). Better still, use http://bugs6.perl.org/ ! > Also, just curious, but is Parrot supposed to be ANSI C, or doesn't it > matter (it has some POSIX-1 stuff in it now)? It *should* be ANSI C, but so long as it runs everywhere, I don't mind. :) -- Writing software is more fun than working.
