Hi,
I found it a bit hard task to follow up the versions of mailman-i18n
because pygettext.py output is random order.
Following patch and executing the script with `--style sort' option
make the output more friendly for translaters, I believe.
Cheers,
Tokio Kikuchi
--- pygettext.py.orig Sat May 19 22:36:57 2001
+++ pygettext.py Sat May 19 22:40:43 2001
@@ -100,6 +100,7 @@
Solaris # File: filename, line: line-number
GNU #: filename:line
+ sort (slightly modified GNU with filename/line order)
The style name is case insensitive. GNU style is the default.
@@ -288,7 +289,27 @@
# The time stamp in the header doesn't have the same format
# as that generated by xgettext...
print pot_header % {'time': timestamp, 'version': __version__}
- for k, v in self.__messages.items():
+ if options.locationstyle == options.SORT:
+ messages = {}
+ for k, v in self.__messages.items():
+ file_line = []
+ i = 0
+ for filename, lineno in v:
+ file_line[i:] = ['#: %s:%05d\n'% (filename,lineno)]
+ i = i + 1
+ file_line.sort()
+ s = ''
+ for f in file_line:
+ s = s + f
+ messages[s] = k
+ x = messages.keys()
+ x.sort()
+ for s in x:
+ print s,
+ print 'msgid', normalize(messages[s])
+ print 'msgstr ""\n'
+ else:
+ for k, v in self.__messages.items():
if not options.writelocations:
pass
# location comments are different b/w Solaris and GNU:
@@ -336,6 +357,7 @@
# constants
GNU = 1
SOLARIS = 2
+ SORT = 3
# defaults
extractall = 0 # FIXME: currently this option has no effect at all.
escape = 0
@@ -351,6 +373,7 @@
options = Options()
locations = {'gnu' : options.GNU,
'solaris' : options.SOLARIS,
+ 'sort' : options.SORT,
}
# parse options
I'm about to change the search order for templates -- you know, those
pesky .html and .txt files that live in $prefix/templates and
$prefix/lists/$mylist. This change is necessary to properly support
language templates, and also provides a much requested feature, namely
that you will only need to specialize templates that you actually want
to change, and that you have multiple levels of specialization.
Here's how it works.
There are 4 levels of template specialization: list-centric,
vhost-centric, site-centric, and default, corresponding to the
directories
$prefix/lists/$listname
$prefix/templates/$host_name
$prefix/templates/site
$prefix/templates
Each of these locations is further organized by language
subdirectories. So let's say you were looking for the listinfo.html
template for list foobar in language es. You'd actually end up
searching 12 directories, with of course, the first hit stopping the
search. Let's say further that list foobar is in the www.foobar.com
virtual domain, and that it's list-preferred language is fr, while the
server's default language is en. Here's the files you'd search for:
$prefix/lists/foobar/es/listinfo.html
$prefix/templates/www.foobar.com/es/listinfo.html
$prefix/templates/site/es/listinfo.html
$prefix/templates/es/listinfo.html
$prefix/lists/foobar/fr/listinfo.html
$prefix/templates/www.foobar.com/fr/listinfo.html
$prefix/templates/site/fr/listinfo.html
$prefix/templates/fr/listinfo.html
$prefix/lists/foobar/en/listinfo.html
$prefix/templates/www.foobar.com/en/listinfo.html
$prefix/templates/site/en/listinfo.html
$prefix/templates/en/listinfo.html
Note that the Mailman 2.0.x search directories of
$prefix/lists/*.{html,txt} and $prefix/templates/*.{html,txt} are
deprecated and no longer searched. The bin/upgrade script will
actually md5 checksum all the old files and remove any templates in
more-specific locations that exactly match their more-general
counterparts.
Any template in $prefix/lists or $templates will have to be moved
manually.
It is highly discouraged that you will ever manually edit a file in
$prefix/templates/$lang, and Mailman's install target will have every
right to overwrite them on an upgrade. That's what the templates/site
subdirectory is for; upgrading will never touch site-centric,
domain-centric, or list-centric templates. Of course, that means it's
up to site administrators to merge in changes to the default
templates.
Watch for checkins shortly.
Comments?
-Barry
I'm a korean.
I installed a mailman to Linux 2.2.18.
I succeed in sending and receiving msg, but in web failed.
In web, I can't read msg in Korean.
How can I do it?
I think, its reason is that in web browser can't decoding that msg.
Shoud I patch about it?
What is the patch program and where I can get it?
Please, help me.
Bak, Yuhyeon.
Vizi Szilard wrote:
>
> I am updating the hungarian catalog, but there are some problems.
>
> The first is: The commandline programs do not use right now the
> translation, although I inserted the DEFAULT_SERVER_LANGUAGE='hu'
> in the mm_cgf.py file. I want to see the hungarian messages in
> the commandline programs, what should I do?
I have discovered why, you must set explicitly language to translate
into.
test in bin/version.py:
import paths
import Mailman.mm_cfg
from Mailman.i18n import _, set_language
set_language(Mailman.mm_cfg.DEFAULT_SERVER_LANGUAGE)
print _('Using Mailman version:'), Mailman.mm_cfg.VERSION
I suppose all scripts in bin must be changed.
>
> And I found some errors:
> - the footer added to every message is still untranslated,
Note it is hard coded in admin pages. mailman only takes what you write.
> - all the commandline programs are writing english messages to the stdout
> - the list archive page is still in english
Yes, it is a work to be done.
I found it very difficult to translate, because the process of archive
generation :-(
You can try it ;-)
I think that the proper persons to do it are mailman managers.
>
> And a suggestion:
> It would be better if definite articles (a, an) could be changed whenever
> it is needed for the next word. In another way:
> - before every word that starting with a vowel (a, e, i, o, u, etc.)
> the article should be 'an', but
> - before a starting consonant (b, c, d, g, etc.) the article='a'
> For example:
> #: /home/mailman/Mailman/Cgi/listinfo.py:112
> msgid " mailing lists on %(hostname)s."
> msgstr " levelezési listák a(z) %(hostname)s gépen." <- right now
> msgstr " levelezési listák %(article)s %(hostname)s gépen." <- modified
>
> And if I have a server with 'ond.vein.hu' hostname, the text will be:
> "levelezési listák az ond.vein.hu gépen."
> And in case of 'listserv.vein.hu':
> "levelezési listák a listserv.vein.hu gépen."
>
> Every translator have to define those letters that goes to the group of
> vowels, and the consonant.
>
> And finally, I have started translating the README.*,FAQ and INSTALL
> files. How should I give name for the translated files?
> 1. README.hu, FAQ.hu, a.s.o., or
> 2. OLVASSEL (this is the Hungarian word for README)
By now I recommend to be README.hu, but must be Barry the one to decide
it.
--
___
/ F \
[[[]]]]
( O O )
#----------------0000--(_)--0000---------------#
| Juan Carlos Rey Anaya (jcrey(a)uma.es) |
| Servicio Central de informática |
| Universidad de Málaga - España |
#----------------------------------------------#
I'm hoping to release a new alpha of Mailman 2.1 some time this week,
and I would love to finalize the integration of the i18n stuff. Below
are my current thoughts on the CVS and distribution structures
necessary to accomplish this. Please comment!
To CVS:
- Each supported language can be checked into the Mailman CVS tree
as follows (for mythical language `xx'):
templates/xx/*.{html,txt} -- these are translated versions of
the English templates
messages/xx/README.xx -- a README file containing useful
information for anybody wanting to use
or modify this translation. It should
include at a minimum the necessary
entry for LC_DESCRIPTIONS. It might
also contain an email address to
contact the xx language's champion or
leader.
messages/xx/LC_MESSAGES/catalog.xx
mailman.mo
-- these are the human readable
translation of the mailman.pot file,
and the binary .mo file
- There will also be a messages/mailman.pot file checked. I will
update that file via pygettext.py when I've piled up enough
changes to the translatable strings.
Distribution
- Mailman will come with a default `en' language containing the
original template files, but with no mailman.mo file.
- Mailman will have a `light' distribution which contains only the
English translations. It might also be worthwhile to distribute
a `sumo' package which contains all the checked-in languages.
- Each language will be separately distributed as a tarball such
that you can run the following in your install directory:
% tar zxf mailman-i18n-xx.tgz
% bin/newlang -l mylist xx
and now language xx will be available to your users (after
changing mm_cfg.py of course).
- Thus, if we have 10 languages checked in, but you're only
interested in 3 of them, you can download the light distro and
then install only the language packs that you want.
I will definitely be looking for volunteers to manage the language
distributions, especially because I expect language updates to happen
asychronously from Mailman versions. I think it will be too much work
for me to keep the languages up-to-date, shepherd the various
translation efforts, do all the language check-ins etc. I'm willing
to give a few volunteers check-in privs to the Mailman tree if they
are willing to manage the language releases. I'll try to write
scripts to make packaging language distros fairly easy.
Have I missed anything?
I'm going to spend a bit of time putting the basics together before I
commit stuff to CVS. If anybody has fairly up-to-date translations of
both the templates and the catalog, please send me a link.
-Barry
Hi all,
I am new to this list and trying to use Mailman
to administer a Japanese language ML.
I have recently installed Mailman. Mailman
no trouble with handling Japanese e-mail messages but
archive files (html) do not display Japanese
characters properly. The problem seems to do
with the html conversion by Mailman.
When Mailman encouters '>' it gets replaced with '>'. In the
case of Japanese (multibyte) messages, this '>' is generally
one byte of double-byte character (Japanese) and as a result
the characters get messed up in html files. Archive files in the
text format does not have this problem.
I am not sure how this problem can be sorted out.
Is there a way wherein the replacement of '>' by '>'
can be avoided. Or is there a way to generate text files
instead of html files.
Thanks in advance.
Venkatesh Raghavan
Osaka City University
Japan
Hi,
I was working on Japanese translation of i18n mailman catalog
and found some sentenses are impossible to be translated
because they are splitted in small pieces.
I submitted a critical patch to sourceforge and would be
happy if you can integrate into next alpha release.
https://sourceforge.net/tracker/index.php?func=detail&aid=420396&group_id=1…
Regards,
Tokio
D> i find you very interting but i dont no understanding correctly
D> your content: send me please the french translation
Please ask on mailman-i18n(a)python.org
