Menu
▾
▴
pidgin-i18n — DO NOT USE. See https://pidgin.im/cgi-bin/mailman/listinfo/translators
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(1) |
Mar
(70) |
Apr
(43) |
May
(57) |
Jun
(84) |
Jul
(22) |
Aug
(20) |
Sep
(17) |
Oct
(8) |
Nov
(1) |
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(12) |
Feb
(58) |
Mar
(34) |
Apr
(65) |
May
(16) |
Jun
(6) |
Jul
(4) |
Aug
|
Sep
|
Oct
(23) |
Nov
(18) |
Dec
|
| 2007 |
Jan
(16) |
Feb
(6) |
Mar
(2) |
Apr
(22) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Richard L. <rl...@wi...> - 2006-02-14 16:21:53
|
On Tue, 2006-02-14 at 15:25 +0100, =D0=94=D0=B0=D0=BD=D0=B8=D0=BB=D0=BE =D0= =A8=D0=B5=D0=B3=D0=B0=D0=BD wrote: > =D0=88=D1=83=D1=87=D0=B5 =D1=83 21:51, Luke Schierer =D0=BD=D0=B0=D0=BF= =D0=B8=D1=81=D0=B0: >=20 > > I strongly agree with Ethan here. No reason why they should have to > > learn UTF-8 when we can automatically convert the encoding at compile > > time. >=20 > You actually can't (or not easily, anyway): intltool is reencoding > only into it's own cache so it can construct properly merged .desktop, > .xml, .schemas, .server and similar files which contain many > languages. Encoding ends up in the MO file as well, and translation > needs to be re-encoded on every run of the program in that locale. Why not just have an intltool-msgfmt script which checks the encoding, and if it's not UTF-8, converts it before passing the contents of the .po to msgfmt? Richard |
|
From: <da...@gn...>
) - 2006-02-14 14:21:56
|
Hi guys, =D0=88=D1=83=D1=87=D0=B5 =D1=83 21:51, Luke Schierer =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0: > I strongly agree with Ethan here. No reason why they should have to > learn UTF-8 when we can automatically convert the encoding at compile > time. You actually can't (or not easily, anyway): intltool is reencoding only into it's own cache so it can construct properly merged .desktop, .xml, .schemas, .server and similar files which contain many languages. Encoding ends up in the MO file as well, and translation needs to be re-encoded on every run of the program in that locale. I've explained this in the bug as well. Also, you can't serve all the PO files properly via web page (or, it's harder at least), like the one on http://gaim.sf.net/i18n/, since you commonly set only a single content-encoding. Cheers, Danilo |
|
From: Bjoern V. <bj...@cs...> - 2006-02-14 11:54:39
|
Shalom Craimer wrote: > After getting the e-mail yesterday about a string-freeze, I=20 > immidiately went and downloaded the gaim.pot from=20 > http://gaim.sourceforge.net/i18n/ and translated all the missing/fuzzy = > strings. Imagine my suprise when today I notice another 6 fuzzy string = > having appeared in the translation. Should I wait until all the=20 > changes are complete? Or: What did I not do right? May be this new strings come from /src/protocols/bonjour/jabber.c. This=20 file was missing in po/POTFILES.in at start of string freeze. I think, this "string freeze" is not a very strict string freeze. The=20 developers fix bugs and _should_ not change strings in the next weeks=20 before 2.0.0 release. And the translators should use this relatively=20 long time for translation. You can send your translation already now for testing. But I think there = will be a few changes until the last days before 2.0.0 release. Two=20 examples: 1) Sometimes a developer must change a string during bug=20 fixing. 2) If a new translation will be included in Gaim, the country=20 name will be added for Gaim->About. Greetings, Bj=F6rn |
|
From: Bjoern V. <bj...@cs...> - 2006-02-14 11:54:24
|
Shalom Craimer wrote: > After getting the e-mail yesterday about a string-freeze, I=20 > immidiately went and downloaded the gaim.pot from=20 > http://gaim.sourceforge.net/i18n/ and translated all the missing/fuzzy = > strings. Imagine my suprise when today I notice another 6 fuzzy string = > having appeared in the translation. Should I wait until all the=20 > changes are complete? Or: What did I not do right? May be this new strings come from /src/protocols/bonjour/jabber.c. This=20 file was missing in po/POTFILES.in at start of string freeze. I think, this "string freeze" is not a very strict string freeze. The=20 developers fix bugs and _should_ not change strings in the next weeks=20 before 2.0.0 release. And the translators should use this relatively=20 long time for translation. You can send your translation already now for testing. But I think there = will be a few changes until the last days before 2.0.0 release. Two=20 examples: 1) Sometimes a developer must change a string during bug=20 fixing. 2) If a new translation will be included in Gaim, the country=20 name will be added for Gaim->About. Greetings, Bj=F6rn |
|
From: Bjoern V. <bj...@cs...> - 2006-02-14 11:43:18
|
Richard Laager wrote:
> What is it that check_po.pl does that msgfmt -c doesn't?
> =20
I think "msgfmt -c" only finds hard errors in .po files. In most cases,=20
the "msgfmt -c" errors prevent the compilation, if they are not fixed:
An example:
#: ../src/ft.c:442
#, c-format
msgid "%s is not a valid filename.\n"
msgstr "%s ist kein g=FCltiger Dateiname."
Because of the missing line ending ("\n") the file can not be compiled.
$ msgfmt -c de.po
de.po:2121: `msgid' and `msgstr' entries do not both end with '\n'
msgfmt: found 1 fatal error
$ make
file=3D`echo de | sed 's,.*/,,'`.gmo && rm -f $file &&
/usr/bin/msgfmt -o $file de.po
de.po:2121: `msgid' and `msgstr' entries do not both end with '\n'
/usr/bin/msgfmt: found 1 fatal error
*** Error code 1
check_po.pl is more a "lint" tool for gettext. It finds very much=20
possible problems in .po files (from check_po.pl):
# Various checks on po file translations:
# - printf-style format strings;
# - differences in trailing newlines;
# - empty (non-fuzzy) msgid;
# - likely whitespace errors on joining multi-line entries
# Ignores all fuzzy entries.
#
# Options:
# -x Don't do standard checks above (eg, just check one of below).
# -n Check newlines within strings; ie, that have equal numbers
# of newlines in msgstr and msgid. (Optional because this may
# happen legitimately.)
# -w Check leading whitespace. Sometimes whitespace is simply
# spacing (eg, for widget labels etc), or punctuation difference=
s,
# so this may be ok.
# -W Check trailing whitespace. See -w above.
# -p Check trailing punctuation.
# -c Check capitalization of first non-whitespace character
# (only if [a-zA-Z]).
# -e Check on empty (c.q. new) msgstr
I use both tools with the following options:
msgfmt:
$ LANG=3DC msgfmt --check --check-accelerators=3D_ -c de.po
This does the standard checks (-c|--check) and also checks presence of=20
keyboard accelerators for menu items.
check_po.pl:
./check_po.pl -xnwWpce de.po
This does not do the standard checks (because I don't want to see all=20
the "*** Possible non-whitespace line-join problem in msgstr" warnings - =
I think this are false-positives). But it checks for other problems like =
different trailung punctuations. See above for the meanings of the other =
switches.
Dear translators: Please use both tools. Especially check_po.pl shows=20
many false-positives. But in most cases, this tools also find "real"=20
problems.
Regards, Bj=F6rn
|
|
From: Shalom C. <scr...@gm...> - 2006-02-14 08:34:06
|
After getting the e-mail yesterday about a string-freeze, I immidiately wen= t and downloaded the gaim.pot from http://gaim.sourceforge.net/i18n/ and translated all the missing/fuzzy strings. Imagine my suprise when today I notice another 6 fuzzy string having appeared in the translation. Should I wait until all the changes are complete? Or: What did I not do right? |
|
From: Richard L. <rl...@wi...> - 2006-02-14 02:17:19
|
What is it that check_po.pl does that msgfmt -c doesn't? Richard |
|
From: Luke S. <lsc...@us...> - 2006-02-13 20:52:30
|
On Mon, Feb 13, 2006 at 03:15:45PM -0500, Ethan Blanton wrote: > Richard Laager spake unto us the following wisdom: > > I'm perfectly okay with ignoring the warnings, but is there any reason > > we couldn't just convert the files? I'd rather not do it myself (because > > I don't want to break something for the translators), but have the > > respective translators do it when they next submit an update. > > There is no reason that translators should not submit pofiles in the > character set they are most comfortable with. The fact that intltool > is crying about it should be considered a bug. > > Ethan I strongly agree with Ethan here. No reason why they should have to learn UTF-8 when we can automatically convert the encoding at compile time. luke |
|
From: Richard L. <rl...@wi...> - 2006-02-13 20:37:20
|
On Mon, 2006-02-13 at 15:15 -0500, Ethan Blanton wrote: > Richard Laager spake unto us the following wisdom: > > I'm perfectly okay with ignoring the warnings, but is there any reason > > we couldn't just convert the files? I'd rather not do it myself (because > > I don't want to break something for the translators), but have the > > respective translators do it when they next submit an update. > > There is no reason that translators should not submit pofiles in the > character set they are most comfortable with. The fact that intltool > is crying about it should be considered a bug. Sure. All I was saying is, if you're a translator for one of these files and you're equally comfortable working with UTF-8, then perhaps you could convert the file for the next update. Anyway, I filed bug #331046 at http://bugzilla.gnome.org against intltool. I just wanted to see if this list had any feedback before I went ahead. Richard |
|
From: Ethan B. <ebl...@cs...> - 2006-02-13 20:15:50
|
Richard Laager spake unto us the following wisdom: > I'm perfectly okay with ignoring the warnings, but is there any reason > we couldn't just convert the files? I'd rather not do it myself (because > I don't want to break something for the translators), but have the > respective translators do it when they next submit an update. There is no reason that translators should not submit pofiles in the character set they are most comfortable with. The fact that intltool is crying about it should be considered a bug. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
|
From: Richard L. <rl...@wi...> - 2006-02-13 19:58:13
|
I'm perfectly okay with ignoring the warnings, but is there any reason we couldn't just convert the files? I'd rather not do it myself (because I don't want to break something for the translators), but have the respective translators do it when they next submit an update. WARNING: ./po/my_MM.po is not in UTF-8 but iso-8859-1, converting... WARNING: ./po/tr.po is not in UTF-8 but ISO-8859-9, converting... WARNING: ./po/nb.po is not in UTF-8 but ISO-8859-1, converting... WARNING: ./po/en_GB.po is not in UTF-8 but iso-8859-1, converting... WARNING: ./po/it.po is not in UTF-8 but iso-8859-1, converting... WARNING: ./po/pl.po is not in UTF-8 but ISO-8859-2, converting... Richard -------- Forwarded Message -------- > From: Rodney Dawes <do...@no...> > To: Richard Laager <rl...@wi...> > Cc: int...@li... > Subject: Re: [Intltool] UTF-8 Conversion Warnings > Date: Mon, 13 Feb 2006 14:32:51 -0500 > > On Mon, 2006-02-13 at 13:14 -0600, Richard Laager wrote: > > On Mon, 2006-02-13 at 13:56 -0500, Rodney Dawes wrote: > > > On Mon, 2006-02-13 at 11:37 -0600, Richard Laager wrote: > > > > Gaim recently switched to using intltool. When we build, we get the > > > > following warnings. The charset is marked in the .po file, and intltool > > > > doesn't seem to report any problems doing the conversion, so why is it > > > > necessary to warn? > > > > > > Becuase your po file says it is UTF-8 but contains characters from other > > > character sets. This means you should fix the po files to actually be in > > > UTF-8 rather than just saying they are, but without converting them. > > > > It doesn't say it's UTF-8. Here's an example of one that's being warned > > about: > > > "Content-Type: text/plain; charset=ISO-8859-2\n" > > > It clearly says ISO-8859-2 and that's what intltool detects it as, given > > the warning is: > > WARNING: ./po/pl.po is not in UTF-8 but ISO-8859-2, converting... > > > > Am I missing something? > > Ah, sorry. OK. So, it's warning because it's not in UTF-8. And po files > should be in UTF-8. Just convert them to UTF-8 or ignore the warning. > The warning is to tell people that they should convert and join the new > millenium. :) > > -- dobey > > |
|
From: Bjoern V. <bj...@cs...> - 2006-02-13 15:12:40
|
Benedikt Wildenhain <ga...@be...> wrote: > I started to make a Translation to Esperanto some days before (until now,= I > only translated almost 200 strings, see > http://www.bwildenhain.de/gaim-eo.pot), is there a simple way to "merge" > this file with the gaim.pot on http://gaim.sourceforge.net/i18n/? And > what should I put into the "Language-Team:"-Field? Yes, you can simply merge the files. There is one way with Gaim's source code from CVS and one without source code, but with the gaim.pot file from http://gaim.sourceforge.net/i18n/. I suggest you the way with the source code, because sometimes you should look into the source code to understand some difficult messages. With the source code: --------------------- # update your Gaim CVS tree (HEAD branch) $ ... $ cd gaim/po # copy your gaim-eo.pot file here (target name: eo.po) $ cp ...gaim-eo.pot eo.po # update your translation file (intltool-update from "intltool"-package) $ intltool-update eo # edit your eo.po file $ ... $ cd .. # edit configure.ac and add "eo" to ALL_LINGUAS # compile and test your translation $ ./autogen.sh ... %% make %% make install Without the source code: ------------------------ # copy gaim-eo.pot and gaim.pot into a directory $ ... # update your translation with gaim.pot (Output: eo.po) $ msgmerge -v gaim-eo.pot gaim.pot -o eo.po # compile eo.po $ msgfmt -v -o eo.gmo eo.po # copy eo.gmo to gaim-install-prefix/???/locale/eo/LC_MESSAGES/gaim.mo $ ... # test it Greetings, Bj=F6rn |
|
From: Javier <jf...@co...> - 2006-02-13 14:52:59
|
On Mon, Feb 13, 2006 at 11:34:11AM +0100, Bjoern Voigt wrote: > Hello Mark! >=20 > Mark Doliner <ma...@ki...> wrote: > >Hello Gaim developers, translators and users! As of nowish, the Gaim > >codebase is in a string-freeze pending the final release of Gaim > >2.0.0. Strange, I didn't receive Mark's original mail. > Are there any ideas, how we should deal with languages with very > incomplete and outdated translations? Ideally we find new translators > for this languages. May be we should ask for help on a translators site > (GNOME translation teams etc.). I wouldd say drop them (i.e. leave the pos but do not compile them in) and ask for new translators either in the GNU Translation project or GNOME team= s. > Should we include translation files with a very low rate of translated > strings? For instance Amharic (am) has currently a translation rate of > 4.95%, Slovak (sk) 5.39% etc. (from http://gaim.sourceforge.net/i18n/) Depends if they are stalled (nobody is working on them) or if they are active. If they are active I'd say keep them (it's frustating to do a translation and not see it included). > I personally prefer English over a very incomplete translation. Me too. But there's people that don't parse English well and maybe seeing a (partial) translation might prompt them to start working if the previous translator is no longer active. Regards Javier |
|
From: Benedikt W. <ga...@be...> - 2006-02-13 11:14:55
|
Hello, On Mon, Feb 13, 2006 at 12:52:15AM -0500, Mark Doliner wrote: > This means that we will try our hardest not to change any strings, so that > translators have time to translate everything to their language. Considering > the amount of code that has changed, we are bound to have added strings and > neglected to mark them as translatable, and for that I apologize. Please let > us know if you run into any problems. Looking at > http://gaim.sourceforge.net/i18n/, it looks like there are about 190 new > strings and 540 fuzzy strings. I started to make a Translation to Esperanto some days before (until now, I only translated almost 200 strings, see http://www.bwildenhain.de/gaim-eo.pot), is there a simple way to "merge" this file with the gaim.pot on http://gaim.sourceforge.net/i18n/? And what should I put into the "Language-Team:"-Field? -- GPG-Key 1024D/E32C4F4B | www.gnupg.org | http://enigmail.mozdev.org Fingerprint = 9C03 86B5 CA59 F7A3 D976 AD2C 02D6 ED21 E32C 4F4B Mit freundlichen Gruessen | Kun afablaj salutoj (www.esperanto.org) May the tux be with you. :wq 73 |
|
From: Bjoern V. <bj...@cs...> - 2006-02-13 10:35:06
|
Hello Mark! Mark Doliner <ma...@ki...> wrote: > Hello Gaim developers, translators and users! As of nowish, the Gaim > codebase is in a string-freeze pending the final release of Gaim > 2.0.0. There is a missing file with i18n strings in POTFILES.in: src/protocols/bonjour/jabber.c The attached patch adds it to POTFILES.in. > [...] Please let us know if you run into any problems. Looking at > http://gaim.sourceforge.net/i18n/, it looks like there are about 190 > new strings and 540 fuzzy strings. Are there any ideas, how we should deal with languages with very incomplete and outdated translations? Ideally we find new translators for this languages. May be we should ask for help on a translators site (GNOME translation teams etc.). Should we include translation files with a very low rate of translated strings? For instance Amharic (am) has currently a translation rate of 4.95%, Slovak (sk) 5.39% etc. (from http://gaim.sourceforge.net/i18n/) I personally prefer English over a very incomplete translation. Regards, Bj=F6rn |
|
From: Mark D. <ma...@ki...> - 2006-02-13 05:47:10
|
Hello Gaim developers, translators and users! As of nowish, the Gaim codebase is in a string-freeze pending the final release of Gaim 2.0.0. This means that we will try our hardest not to change any strings, so that translators have time to translate everything to their language. Considering the amount of code that has changed, we are bound to have added strings and neglected to mark them as translatable, and for that I apologize. Please let us know if you run into any problems. Looking at http://gaim.sourceforge.net/i18n/, it looks like there are about 190 new strings and 540 fuzzy strings. Developers! Please try not to make any major changes until after 2.0.0 is released. The closer we get to 2.0.0, the more important this becomes. Let's aim to have everything translated and bugfixed in three weeks. If we need more time then we can push back the release a little. Today is February 12th. Let's try to have everything finished by March 5th. Now is the spring of our disco continent, Mark Doliner |
|
From: Richard L. <rl...@wi...> - 2006-02-13 02:47:38
|
On Sat, 2006-02-11 at 23:06 +0100, Bjoern Voigt wrote: > I see one problem with this approach. The step 2 may not be possible > without loosing information, if the user sets an unsuitable locale > charset. I'm aware this is a possibility. > 1) Set LC_CTYPE=3DUTF-8 within Gaim. The only problem here is to find t= he > "UTF-8" name (LC_CTYPE value) for each system. On Linux it's "utf8"= , > on Solaris and FreeBSD it's "UTF-8". I prefer this solution because > of it's simplicity. But where do we found the necessare UTF-8 local= e > names? Ethan Blanton wrote about this problem. If you find a semi-reliable way to do this, I'm all for it. We can always fall back to the behavior we have now if we can't find a UTF-8 locale. However, I'm too busy to try to figure this out. Patches are always wonderful. ;) > 2) Usage of date/time strings which only have ASCII-value placeholders > (regardless of locale). This means, that we can not use names for > days, months etc. (%A, %B, ...) but numbers (%d, %m, ...). This > date/time strings for strftime() should be still marked as > translatable for the reasons which were explained by Ambrose Li. ... > The attached patch changes the two problematic date/time strings > according to solution 2. Please test this patch and write your comments. To be perfectly blunt, I'm not going to sacrifice nice dates for English speakers for non-English speakers in non-UTF8 locales, who *might* have a problem, depending on how various translations are done. This is ONLY a problem if you stick words in the translation... For example, using your example of "Erd=C3=B6l" (... note I have no idea what this word mean= s in English...), if you translate "%x %X" to "%X Erd=C3=B6l %x", then you wil= l have problems if the user's character LC_CTYPE is "C", for example. However, if you only translate it to "%X, %x", then you're fine. If you or another translator is worried about this problem for speakers of their language, they are free to translate "%B %Y" to "%m/%Y", "%x % X" to "%m/%d/%Y %I:%M:%S %p", etc. as your patch suggests. Richard |
|
From: Richard L. <rl...@wi...> - 2006-02-13 02:47:37
|
On Sun, 2006-02-12 at 23:56 +0100, Bjoern Voigt wrote: > The POTFILES.in checking command "intltool-update -m" shows some > warnings about mismatched quotes: > > $ cd po > $ intltool-update -m > mismatched quotes at line 296 in ../plugins/ssl/ssl-nss.c > mismatched quotes at line 161 in ../src/gaim-remote.py > mismatched quotes at line 185 in ../src/gaim-remote.py > mismatched quotes at line 190 in ../src/gaim-remote.py > mismatched quotes at line 62 in ../src/gaim-notifications-example.py > mismatched quotes at line 80 in ../src/gaim-notifications-example.py > mismatched quotes at line 81 in ../src/gaim-notifications-example.py > > The first warning can be avoided with the attached patch. Thanks for the patch. I've silenced the ones in src/gaim-notifications-example.py by changing the python code, even though there's nothing wrong with it. However, it would be messy to change the stuff in gaim-remote.py, so I didn't. I've filed bug #330948 at http://bugzilla.gnome.org. Richard |
|
From: Bjoern V. <bj...@cs...> - 2006-02-12 22:57:22
|
Hello!
The POTFILES.in checking command "intltool-update -m" shows some
warnings about mismatched quotes:
$ cd po
$ intltool-update -m
mismatched quotes at line 296 in ../plugins/ssl/ssl-nss.c
mismatched quotes at line 161 in ../src/gaim-remote.py
mismatched quotes at line 185 in ../src/gaim-remote.py
mismatched quotes at line 190 in ../src/gaim-remote.py
mismatched quotes at line 62 in ../src/gaim-notifications-example.py
mismatched quotes at line 80 in ../src/gaim-notifications-example.py
mismatched quotes at line 81 in ../src/gaim-notifications-example.py
The first warning can be avoided with the attached patch.
Does anyone know, how to avoid the warnings about the Python-comments?
For instance, this are the lines 160-161 of src/gaim-remote.py:
if len(sys.argv) =3D=3D 1:
print """This program uses DBus to communicate with gaim.
Greetings, Bj=F6rn |
|
From: Bjoern V. <bj...@cs...> - 2006-02-11 22:07:12
|
Richard Laager <rl...@wi...> wrote:
> I imagine the correct approach is this:
>
> 1. Pass the format string from Gaim to gettext().
> 2. Convert the output from gettext() from UTF-8 to locale format.
> 3. Pass the translated, locale-converted string to strftime().
> 4. Convert the output of strftime() back to UTF-8.
>
> Thoughts?
I see one problem with this approach. The step 2 may not be possible
without loosing information, if the user sets an unsuitable locale
charset.
I mean, that a conversion from UTF-8 to locale charset and back to UTF-8
may change the message:
message !=3D conv(conv(message, UTF-8, localecharset), localecharset, UTF-8=
)
I do not know, if this is an issue in many languages and locale setups.
But already in German it can be an issue:
In normal case the locale charset (LC_CTYPE) and the language
selection (LC_MESSAGES or LANG) should have compatible values. For
instance the locale German/Germany (de_DE) has the following
compatible charsets in (SuSE) Linux: ISO-8859-1, ISO-8859-15 and
UTF-8. But it's also possible to use "C" or "POSIX" as the charset
(LC_CTYPE) selection for German. Then a word like Erd=F6l (lets say in
UTF-8) is converted to Erd"ol (in ASCII/POSIX). Unfortunately the
conversation from Erd"ol to another charset (for instance UTF-8) is
always Erd"ol, but not Erd=F6l (original).
As a result the user may see the date/time strings with garbage in some
locale setups.
I see the following better solutions (which still have problems):
1) Set LC_CTYPE=3DUTF-8 within Gaim. The only problem here is to find the
"UTF-8" name (LC_CTYPE value) for each system. On Linux it's "utf8",
on Solaris and FreeBSD it's "UTF-8". I prefer this solution because
of it's simplicity. But where do we found the necessare UTF-8 locale
names? Ethan Blanton wrote about this problem.
2) Usage of date/time strings which only have ASCII-value placeholders
(regardless of locale). This means, that we can not use names for
days, months etc. (%A, %B, ...) but numbers (%d, %m, ...). This
date/time strings for strftime() should be still marked as
translatable for the reasons which were explained by Ambrose Li.
Example:
English (original): _("%m/%d/%Y %H:%M") -> 02/11/2006 22:27
German (translated): "%d.%m.%Y %H:%M" -> 11.02.2006 22:27
With this solution we do not need a character conversation. The user
can pass UTF-8 via gettext() into strftime(). strftime() fills the
placeholders with ASCII characters (numbers) into the UTF-8 date/time
string.
The attached patch changes the two problematic date/time strings
according to solution 2. Please test this patch and write your comments.
Regards, Bj=F6rn |
|
From: Richard L. <rl...@wi...> - 2006-02-10 20:41:58
|
On Fri, 2006-02-10 at 14:37 -0500, Ethan Blanton wrote: > Yeah, this might be the best way to do it ... but it's disgusting. > The Right Way to do it would be to set the locale to a UTF-8 locale > within Gaim, but unfortunately locale names are not at all portable. > I just poked through the locale functions, and didn't see a good way > to bind the current charset to UTF-8 regardless of locale. Ugh. Indeed. This will get better as people switch to UTF-8 as their charset. Then the conversion functions just become strdup()s. (And, as a side note, I'd like to someday optimize those out using Stringrefs, but that's a discussion for another day.) Thanks for the sanity check on this. I'm still fairly new to internationalization. Richard |
|
From: Ethan B. <ebl...@cs...> - 2006-02-10 19:37:52
|
Richard Laager spake unto us the following wisdom: > The formatters passed to strftime() expand to strings in locale format. > Thus, to use them in Gaim, we convert the output of strftime() to UTF-8. Ahh, I didn't understand your question the first time around. This is kind of ugly. > I imagine the correct approach is this: >=20 > 1. Pass the format string from Gaim to gettext(). > 2. Convert the output from gettext() from UTF-8 to locale format. > 3. Pass the translated, locale-converted string to strftime(). > 4. Convert the output of strftime() back to UTF-8. Yeah, this might be the best way to do it ... but it's disgusting. The Right Way to do it would be to set the locale to a UTF-8 locale within Gaim, but unfortunately locale names are not at all portable. I just poked through the locale functions, and didn't see a good way to bind the current charset to UTF-8 regardless of locale. Ugh. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
|
From: Richard L. <rl...@wi...> - 2006-02-10 18:54:35
|
On Thu, 2006-02-09 at 21:09 +0100, Bjoern Voigt wrote: > I also do not see a solution in converting the UTF-8 date/time string > before passing into strftime(). Since the UTF-8 chars are needed (for > instance in Chinese), you had to convert the charset twice: > 1) UTF-8 (gettext-output) to ASCII (strftime-input) > 2) ASCII to UTF-8 (strftime-out) to GTK+ Not ASCII, but locale format. The formatters passed to strftime() expand to strings in locale format. Thus, to use them in Gaim, we convert the output of strftime() to UTF-8. Now, what happens if we pass in a UTF-8 string (including formatters) to strftime()? We get output that consists of a combination of locale and UTF-8 format. Obviously, this works if the locale format is UTF-8. But, if the local format is an 8 bit character set, it seems to me like things wouldn't work. I imagine the correct approach is this: 1. Pass the format string from Gaim to gettext(). 2. Convert the output from gettext() from UTF-8 to locale format. 3. Pass the translated, locale-converted string to strftime(). 4. Convert the output of strftime() back to UTF-8. Thoughts? Richard |
|
From: Bjoern V. <bj...@cs...> - 2006-02-10 08:30:55
|
Luke Schierer <lsc...@us...> wrote: > On Fri, Feb 10, 2006 at 01:33:05AM +0200, Shalom Craimer wrote: >> This might be a really stupid question, but how does this change affect = a >> stupid translater such as myself? Can I no longer submit .po files? What >> formats do I need to use now? >> >> -=3D Shalom > > You can still submit .po files. This affects only what tools are > available to help you manage your .po file. Yes, you can translate the .po files like before. You can also use the same tools with one exception. The Gaim update.pl script is replaced with intltool-update. intltool-update is part of the intltool-package (included in Linux distributions). Look at my previous mail or at the manual pages for intltool usage. With intltool it's possible to translate the localized names in gaim.desktop within a .po file. Greetings, Bj=F6rn |
|
From: Luke S. <lsc...@us...> - 2006-02-10 00:15:32
|
On Fri, Feb 10, 2006 at 01:33:05AM +0200, Shalom Craimer wrote: > This might be a really stupid question, but how does this change affect a > stupid translater such as myself? Can I no longer submit .po files? What > formats do I need to use now? > > -= Shalom You can still submit .po files. This affects only what tools are available to help you manage your .po file. luke |
9 messages has been excluded from this view by a project administrator.
