Re: Comparing methods
On 22/04/2006, at 1:17 AM, Danilo Šegan wrote:
On April 15th, Christian Rose wrote:
However, concerning new features, the translation status pages have
basically been unmaintained for several years now.
"There are lies, damned lies and statistics."
That is changing. Look forward to reading more about Damned Lies
("damned-lies" in CVS, preview on http://l10n-status.pemas.net/) in
the following days.
Anyone, feel free to start a page on live.gnome.org to request things
you find useful and discuss them.
This looks good! :)
Danilo, the one thing I've seen on the KDE status pages [1] that
would really help me at Gnome is the embedded nature of the webpages.
I don't have to leave the status pages to find links to other i18n
information like the Howto, team list, language list etc.
The side-bar, search bar, integral program crumb trial and drop-down
language-list are real time-savers, and keep the whole thing in front
of you, which actually saves brain cycles.
Can we do something like that?
(I'll put a wiki page up tomorrow, if someone else doesn't do it first.)
from Clytie (vi-VN, Vietnamese free-software translation team / nhóm
Việt hóa phần mềm tự do)
http://groups-beta.google.com/group/vi-VN
[1] e.g. http://l10n.kde.org/stats/gui/trunk/vi/ (and no rude
comments about our stats, we started from zero only recently ;) )
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
On e-mail spams (Was: Re: Comparing methods)
O/H Danilo Šegan έγραψε: Yesterday at 18:17, Simos Xenitellis wrote: There is one thing I would like to comment on, the use of e-mail addresses in HREF links. Those will be replaced with links to eg. /people/simos where we'll list your contact e-mail(s). This is very often the source of spam. However, note that Gnome servers have excellent spam protection (much better than gmx.net one, in my experience, since my @gnome.org is forwarded to @gmx.net ;). Also, generally, you can't avoid spam today. I receive spam on a completely private e-mail address I have never-ever given to more than a dozen people, and all of them are aware enough not to publish it anywhere. Probably if I used some obfuscated alias it wouldn't get found. [btw, I found greylisting to filter more than 90% of spam for me] Spammers generally collect e-mails addresses from Websites or Web directories of users. Once your e-mail is in their list, you cannot get it out and you are stuck in a loop. In some cases they "guess" potential e-mail addresses; for example they know that there exists "danilo" in several mail servers, therefore there is high probability a "danilo" in gmail as well (I do not know if you have such a gmail address). A good mail server should not reply straight away that an e-mail exists or not. It should receive the mail and send the the Delivery Failed message after some hours, when the spammer is offline. That's what gmail does and it's good. In other cases, one of your contacts may get a spamming trojan on their computer that sends off spams. As far as I know, this lasts as long as the computer is infected. Spamming is not inevitable. To see whether your e-mail address has been publicised on the Web, one way is to google for it. An easy fix is to use Javascript to obfuscate the e-mail addresses. This will require JavaScript capable Web browsers in order to view the addresses. For more on this, google on "javascript obfuscate e-mail address". That sounds a bit limiting, IMO. If it's really a problem, we can simply remove e-mails, or provide a direct "contact by e-mail form" so you'll get coordinator e-mail only if he actually responds ;) That would be a very option as well. Cheers, Simos ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Comparing methods
Yesterday at 18:17, Simos Xenitellis wrote: > There is one thing I would like to comment on, the use of e-mail > addresses in HREF links. Those will be replaced with links to eg. /people/simos where we'll list your contact e-mail(s). > This is very often the source of spam. However, note that Gnome servers have excellent spam protection (much better than gmx.net one, in my experience, since my @gnome.org is forwarded to @gmx.net ;). Also, generally, you can't avoid spam today. I receive spam on a completely private e-mail address I have never-ever given to more than a dozen people, and all of them are aware enough not to publish it anywhere. Probably if I used some obfuscated alias it wouldn't get found. [btw, I found greylisting to filter more than 90% of spam for me] > An easy fix is to use Javascript to obfuscate the e-mail > addresses. This will require > JavaScript capable Web browsers in order to view the addresses. > For more on this, google on "javascript obfuscate e-mail address". That sounds a bit limiting, IMO. If it's really a problem, we can simply remove e-mails, or provide a direct "contact by e-mail form" so you'll get coordinator e-mail only if he actually responds ;) Cheers, Danilo ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Comparing methods
O/H Danilo Šegan έγραψε:
On April 15th, Christian Rose wrote:
However, concerning new features, the translation status pages have
basically been unmaintained for several years now.
"There are lies, damned lies and statistics."
That is changing. Look forward to reading more about Damned Lies
("damned-lies" in CVS, preview on http://l10n-status.pemas.net/) in
the following days.
Anyone, feel free to start a page on live.gnome.org to request things
you find useful and discuss them.
The new stats look awesome!
There is one thing I would like to comment on, the use of e-mail
addresses in HREF links.
This is very often the source of spam.
An easy fix is to use Javascript to obfuscate the e-mail addresses. This
will require
JavaScript capable Web browsers in order to view the addresses.
For more on this, google on "javascript obfuscate e-mail address".
Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Comparing methods
On April 15th, Christian Rose wrote:
> However, concerning new features, the translation status pages have
> basically been unmaintained for several years now.
"There are lies, damned lies and statistics."
That is changing. Look forward to reading more about Damned Lies
("damned-lies" in CVS, preview on http://l10n-status.pemas.net/) in
the following days.
Anyone, feel free to start a page on live.gnome.org to request things
you find useful and discuss them.
Cheers,
Danilo
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Comparing methods
On 16/04/2006, at 6:56 PM, Christian Rose wrote: Perhaps this will become easier when we move to Pootle. I do not know. Perhaps someone experienced working with Pootle can answer that. (And I do not know when Pootle will happen, either) I'll Dwayne on the Pootle list. :) Umm, what I meant to say was "I do not know when the GTP will have Pootle". I think the Pootle maintainers are not to blame for that. :-) And what I meant, was I'd him to find out whether grabbing all POT files, for instance, would be easier when using Pootle. I'll be very happy when we have Pootle available in Gnome, but I realize that won't happen overnight. :) from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do) http://groups-beta.google.com/group/vi-VN ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Comparing methods
On 4/15/06, Clytie Siddall <[EMAIL PROTECTED]> wrote: > >> However, I don't think you can update all the POTs, for example, for > >> a range of separate directories, without updating everything else. > >> Having all the POTs in one directory really does help. > > > > However, I do appreciate that having a simple way of getting all the > > current POT files helps new teams a lot. As a consequence, years ago I > > requested there be a link on the status pages where you could download > > a tarball with "all current POT files for developer-libs" and a > > tarball with "all current POT files for desktop". I imagine that would > > not be a very complicated feature to add. > > Yes, this is the part that I also think could be useful. I gather it > didn't happen... Correct. > > Perhaps this will become easier when we move to Pootle. I do not know. > > Perhaps someone experienced working with Pootle can answer that. > > (And I do not know when Pootle will happen, either) > > I'll Dwayne on the Pootle list. :) Umm, what I meant to say was "I do not know when the GTP will have Pootle". I think the Pootle maintainers are not to blame for that. :-) Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Comparing methods
On 15/04/2006, at 11:44 PM, Åsmund Skjæveland wrote: $LANG_CODE=nn Oops. Cancel that '$'. That line should read: LANG_CODE=nn Thanks. Fixed. ;) from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do) http://groups-beta.google.com/group/vi-VN ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Comparing methods
On 15/04/2006, at 11:40 PM, Åsmund Skjæveland wrote: However, I do appreciate that having a simple way of getting all the current POT files helps new teams a lot. As a consequence, years ago I requested there be a link on the status pages where you could download a tarball with "all current POT files for developer-libs" and a tarball with "all current POT files for desktop". I imagine that would not be a very complicated feature to add. Yes, this is the part that I also think could be useful. I gather it didn't happen... Missing features leads to lots of people thinking up their own hacks. For example, here's a bash script that downloads the files for one language for you: Ooh, kewl. :) Set LANG_CODE to your language code, of course. I don't know if it'll work on Mac (you need a bourne shell and wget). Mac OSX is UNIX (BSD), so it should work perfectly, thankyou! bash is the default shell now (it used to be tcsh, so I had to specify bash then). We should have this script in the wiki, linked from one of the GTP pages. from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do) http://groups-beta.google.com/group/vi-VN ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Comparing methods
> Missing features leads to lots of people thinking up their own hacks.
> For example, here's a bash script that downloads the files for one
> language for you:
>
> $LANG_CODE=nn
Oops. Cancel that '$'. That line should read:
LANG_CODE=nn
--
Åsmund Skjæveland {
[EMAIL PROTECTED]
}
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Comparing methods
> >However, I do appreciate that having a simple way of getting all the
> >current POT files helps new teams a lot. As a consequence, years ago I
> >requested there be a link on the status pages where you could download
> >a tarball with "all current POT files for developer-libs" and a
> >tarball with "all current POT files for desktop". I imagine that would
> >not be a very complicated feature to add.
>
> Yes, this is the part that I also think could be useful. I gather it
> didn't happen...
Missing features leads to lots of people thinking up their own hacks.
For example, here's a bash script that downloads the files for one
language for you:
$LANG_CODE=nn
for i in desktop developer-libs proposed;
do
mkdir -p $i;
cd $i;
wget -r -l 1 -N -nd -A"*.po,*.pot"
http://l10n-status.gnome.org/gnome-2.14/$LANG_CODE/$i/;
cd ..;
done
-N is a timestamp check, but it's only there to save a little
bandwith. wget will happily overwrite any files already in the
directory.
Set LANG_CODE to your language code, of course. I don't know if it'll
work on Mac (you need a bourne shell and wget).
--
Åsmund Skjæveland {
[EMAIL PROTECTED]
}
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Comparing methods
Thanks for your reply, Christian. :) On 15/04/2006, at 6:50 PM, Christian Rose wrote: On 4/15/06, Clytie Siddall <[EMAIL PROTECTED]> wrote: When I started, I thought keeping PO files in a separate directly was a bad idea. It distanced the PO file from the source. I am still of that opinion. :-) Having the PO files in the applications makes it easier to find internationalization bugs in the applications and gives important context to translators who can read source code. True. This is my overall opinion, too. Also, half the time in KDE, I don't even know to which applications the files belong. That makes it extremely difficult to report typos against them (as does the five-page bug-reporting "wizard" that wants my name, serial number and favourite type of noodles before I can report simple typos). However, I don't think you can update all the POTs, for example, for a range of separate directories, without updating everything else. Having all the POTs in one directory really does help. However, I do appreciate that having a simple way of getting all the current POT files helps new teams a lot. As a consequence, years ago I requested there be a link on the status pages where you could download a tarball with "all current POT files for developer-libs" and a tarball with "all current POT files for desktop". I imagine that would not be a very complicated feature to add. Yes, this is the part that I also think could be useful. I gather it didn't happen... However, concerning new features, the translation status pages have basically been unmaintained for several years now. That's a great pity. :( Perhaps this will become easier when we move to Pootle. I do not know. Perhaps someone experienced working with Pootle can answer that. (And I do not know when Pootle will happen, either) I'll Dwayne on the Pootle list. :) from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do) http://groups-beta.google.com/group/vi-VN ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Comparing methods
On 4/15/06, Clytie Siddall <[EMAIL PROTECTED]> wrote: > When I started, I thought keeping PO files in a separate directly was > a bad idea. It distanced the PO file from the source. I am still of that opinion. :-) Having the PO files in the applications makes it easier to find internationalization bugs in the applications and gives important context to translators who can read source code. > However, I don't think you can update all the POTs, for example, for > a range of separate directories, without updating everything else. > Having all the POTs in one directory really does help. However, I do appreciate that having a simple way of getting all the current POT files helps new teams a lot. As a consequence, years ago I requested there be a link on the status pages where you could download a tarball with "all current POT files for developer-libs" and a tarball with "all current POT files for desktop". I imagine that would not be a very complicated feature to add. However, concerning new features, the translation status pages have basically been unmaintained for several years now. Perhaps this will become easier when we move to Pootle. I do not know. Perhaps someone experienced working with Pootle can answer that. (And I do not know when Pootle will happen, either) Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Comparing methods
On 14/04/2006, at 6:07 PM, Åsmund Skjæveland wrote (in part): The path magic already in the PO Auxillary dialog is designed for the KDE file hierarchy, which keeps PO files separate from application source, in a separate directory for each language. I only started translating for KDE a few weeks ago. (Our team had been dead, completely, for four years! Non-supported. :( ) When I started, I thought keeping PO files in a separate directly was a bad idea. It distanced the PO file from the source. However, I must admit, the convenience, for SVN, is huge. You're not having to add/update/commit single files in single directories: you can add/update/commit all the changes in a whole section (say, all of Gnome Desktop) at once. I do have a svn front end [1] which provides a "flat view", so you can see (and add/update/commit) all the changed files in any "root" directory. I don't know how easy that is to do from the command-line. However, I don't think you can update all the POTs, for example, for a range of separate directories, without updating everything else. Having all the POTs in one directory really does help. I suppose I only need this type of POT access, because my team has had to start its KDE translations from the beginning again, so we're doing a lot of work with POT files. But every team starting work in any section will be in the same situation. This has probably been discussed here before, since some of us work for both Gnome and KDE. What do other translators think? For the new translators, in particular, would it be more useful to have all the POTs for any release in one directory (even as copies)? (I hope it's OK to bring this up. It seems useful to me.) from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do) http://groups-beta.google.com/group/vi-VN [1] svnX, on Mac OSX http://www.lachoseinteractive.net/en/community/subversion/svnx/features/ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
