Marking translatable strings

[Calvelo Daniel]

Barry A. Warsaw <bwarsaw at beopen.com> wrote:

:     >> 1. It seems to me that the natural extension of the current
:     >> string syntax is to allow a prefix 't' in front of strings
:     >> intended to be translated.
:
:>>>>> "FP" == ISO  <pinard at iro.umontreal.ca> writes:
:
:     FP> It could be a good idea, yet it represents a change in the
:     FP> language, which I think could easily be avoided.
:
: I agree.  I'm especially worried about the proliferation of string
: prefixes we already have: u and r, and some folks have proposed $
: strings.  The addition of t-strings just seems like going overboard to
: me.  Plus, there's no way this is going into 2.0 and I won't speculate
: on Guido's opinion of it for subsequent releases.

I'd say the "natural" prefix would be '_' :) That would mean adding another
prefix, which I agree isn't nice. And then you have the problem of the 
external translation apparatus (especially the myriad translation files). 

Plus, you can have r-docstrings. Would you have t-docstrings? How would you 
handle them? (I'm not sure whether having translatable docstrings is a good 
idea at the base, but...)

I often felt the need for translatable docstrings (especially because of
gendoc and the like), but haven't found a clean way of defining them.
Any ideas?

There is already a gettext-like system, so maybe we should stick to it, 
so we could define a i18n-translatable-docstring as:

class ified:
  _("classified english docstring")
  ...

If the '_()' function had a way of knowing what its context is, it might 
replace the docstring iff it were empty. It's not feasible now, is it?
2.0, maybe?

Am I making any sense? 

-- Daniel Calvelo Aros
     calvelo at lifl.fr