[Paul Prescod] > I think that what I hear you saying is that interpolation should ideally > be done at a compile time for simple uses and at runtime for i18n. > [...] If "%" survives, it would be used for positional parameters, > instead of named parameters. [...] I think we are making progress > if we're coming to understand that the two different problem domains > (simple scripts versus i18n) have different needs and that there is > probably no one solution that fits both. [Moore, Paul] > The internationalisation issue is clearly important. However, it has > very different characteristics insofar as the template string is (of > necessity) handled at runtime, so issues of compilation and security > become relevant. I'm no I18N expert, so I can't comment on details, > but I *do* think it's worth separating out the I18N issues from the > "simple interpolation" issues... You know, the ultimate goal of internationalisation, for a non English speaking user and even programmer, is to see his/her own language all over the screen. This means from the shell, from the system libraries, from all applications, big or small, everything. For what is provided by other programmers or maintainers, this may occur sooner and later, depending on the language, the interest of the maintainer, and the development dynamic. The far-reaching hope is that it will eventually occur. For what a user/programmer writes little things himself/herself, and this is where Python pops up, there are two ways. The simplest is to write all strings in native language. The other way, meant to help exchange with various friends or get feedback from a wider community, is to do things properly, and internationalise even small scripts from the start. It is easy to develop such an attitude, yet currently, examples do not abound. I surely had it for a few languages, despite it was rather demanding on me, at the time `gettext' was not yet available -- and in fact, my works were used to benchmark various ideas before `gettext' was first written. The mantra I repeated all along had two key points: 1) internationalisation will only be successful if designed to be unobtrusive, otherwise average maintainers and implementors will resist it. 2) programmer duties and translation duties are to be kept separate, so these activities could be done asynchronously from one another.[1] I really, really think that with enough and proper care, Python could be set so internationalisation of Python scripts is just unobtrusive routine. There should not be one way to write Python when one does not internationalise, and another different way to use it when one internationalises. The full power and facilities of Python should be available at all times, unrelated to internationalisation intents. Non-English people should not have to pay a penalty, or if they do, the penalty should be minimised As Much As Possible. Our BDFL, Guido, should favour internationalisation as a principle in the evolution for the language, that is, more than a random negligible feature. I sincerely hope he will do. For many people, internationalisation issues cannot be separated out that simply, or otherwise dismissed. We should rather learn to collaborate at properly addressing and solving them at each evolutionary step, so Python really remains a language for everybody. -------------------- [1] In practice, we've met those two goals only partly. For C programs, the character overhead per localised string is low -- the three characters "_()", while exceptionally _not_ obeying the GNU standard about a space before the opening parenthesis. The glue code is still small -- yet not as small as I would have wanted. I wrote the Emacs PO mode so marking strings in a C project can be done rather quickly by maintainers, and so translators can do their job alone. These are on the positive side. But I think we failed at the level of release engineering, as the combined complexity of Automake, Autoconf, Libtool and Gettext installation scripts is merely frightening, and very discouraging for the casual user. There were reasons behind "releng" choices, but they would make a long story. :-) Also, people in the development allowed more fundamental unneeded complexities, and which had to sad effect of anchoring the original plans to the point of being stuck. On the other hand, people not understanding where we were aiming, are happily unaware of what we are missing. (Maintainers may become incredibly stubborn, when having erections. :-) Eh, that's life... Sigh! Python can do better on _all_ fronts. By the way, I hope that `distutils' can be adapted to address internationalisation-related release engineering difficulties, so these merely vanish in practice for Python lovers. We could also have other standard helper tools for non-installed scripts. -- François Pinard http://www.iro.umontreal.ca/~pinard
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4