Re: Creating a New locale
U+0331 looks right indeed. Evolution displayed u+0331 correctly. Thanks, will keep you posted. picFanen Ahua Random quote: Overload -- core meltdown sequence initiated. On Tue, 2009-01-20 at 23:26 -0500, Thomas Thurman wrote: > > U+0331 COMBINING MACRO BELOW: fe̱ed fo̱od > > U+0332 COMBINING LOW LINE: fe̲ed fo̲od > > Receiving my own message back again, Thunderbird had problems with > U+0332 and U+0332 also doesn't work in "view source" for the web page, > whereas U+0331 works fine for both. So I think U+0331 should be what > you want, assuming it looks like the character you're looking for. > > peace > > Thomas signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Well, I'm sure the devels are able to make the system work in anyway they choose, that's why I yell so loudly to get all the po files of one language into one single directory. Now that would cut down the maintenance. If you take a look the translation process, you see, that it consists of 3 major steps. Acquiring the file(s) to translate, translating and commiting. When you "choose" the file, you have to know what is already translated, what is reserved, proofed ... or under revision. You also have to have a quick access to pot files. How many clicks you need to do that? If it's more than one after visiting the page from your favorite bar, there is something like click/bandwidth/time, that can be improved, right? Translation by itself is an individual project and has nothing to do with the git or svn. How many times did you "correct" a single word, that was not syncd in many translations? Last time I did that I had to "repair" 17 files. Why carry apple by apple from the market if you can take a basket with you. If you need more than one line in svn/git or one click on the website more than it's necessary, there is space for improvement, rignt. Getting the files up and down should mean NO effort. It should be easier then ftp-ing them to some server. The real work, with all the logging and diffing, crediting, upgrading and stuff should start from that point on. The last maintainer quit being a mantainer, because he had no time. The last zip that I sent him for 2.22 some time ago had 83 upgraded files. If someone sends me 83 files to commit, I'd break down and cry ... Then I'd start again yelling about SINGLE FOLDER for one language. Less time needed, less bandwidth, less clicks, less nerves, more translating and proofing. A winning situation. M! On Tue, Jan 20, 2009 at 4:55 PM, Kenneth Nielsen wrote: > 2009/1/19 Matej Urban : >> Thanks, Gil, >> >> I will wait and see, but since I'm a translator/mantainer and since I >> doubt I will be able to upload many files at once, the only difference >> so far I see, is that I will replace keyboard keystrokes for mouse >> clicks. There will be no changelog, which is an improvement :) > > I don't see how this solution will NOT improve your situation. When > you want to commit you just have to upload a file via a web-interface. > Which means that you cut both space and bandwitdth down to a minimum, > the only thing left is time. You do save the time it takes out to > check out the modules and fill out the ChangeLog, but you do not get > to save the time you could if you could commit more files at once. But > in my opinion that should never be made a possibility (and I'm a > translation coordinator not a developer), you use verision control > systems (of any kind) to track changes, which makes it easy to revert > if you do something wrong, but that hardly makes sense if you commit > very large changes. > > Regards Kenneth > > PS: I have a commit script I can send you if you want to use it in the > meantime, but let me know only if you want to use it as I would have > to nicefy it a bit before ot could be used by others. > >> >> Anyhow, in the end I will use whatever I'll need to do it, but keep >> nagging about it. For some reason, I really doubt that single dir for >> all po files, is a big programing deal. No obsolete clicks, no hassle, >> just pure translation work. >> >> Matej >> >> On Mon, Jan 19, 2009 at 1:46 PM, Gil Forcada wrote: >>> Hi, >>> >>> Actually a lot has changed: >>> >>> - for advanced-translators the same workflow will be maintained. >>> - for plain translators a web interface to commit languages will be >>> provided. >>> >>> So I think you fall in the second option and thus you will need to have >>> access to http://l10n.gnome.org to download updated po files (like you >>> can do right know), track its status (like as of January you can do >>> right now) and commit them in source repositories (like you will be able >>> to do in a not-so-distant-future, Claude said it has a beta working >>> version that does this, I'm right Claude?) >>> >>> So, all in all, your workflow will be a lot improved since you will only >>> have to download and upload files from/to http://l10n.gnome.org :) >>> >>> Hope I haven't said any lie! >>> >>> Cheers, >>> >>> El dl 19 de 01 de 2009 a les 13:38 +0100, en/na Matej Urban va escriure: Hello, I'm really trying to understand the changes. The title sais: Using Git and separating translations into their own l10n-LL repository The title implies that ALL and ONLY po files from ALL the languages UI and HELP will fall into "l10n-LL" repository, but that will not be the case, as I understand. I really don't know why this is so unpopular among developers. I posted a bug http://bugzilla.gnome.org/show_bug.cgi?id=554257 and also a reminder that I don't fill-in the changelog entries. I can not find those great "scripts" in the gnome archive, that will do all the >
Re: Using Git and separating translations into their own l10n-LL repository
On Wed, Jan 21, 2009 at 8:27 AM, Matej Urban wrote: > Well, I'm sure the devels are able to make the system work in anyway > they choose, that's why I yell so loudly to get all the po files of > one language into one single directory. Now that would cut down the > maintenance. > > If you take a look the translation process, you see, that it consists > of 3 major steps. Acquiring the file(s) to translate, translating and > commiting. > > When you "choose" the file, you have to know what is already > translated, what is reserved, proofed ... or under revision. You also > have to have a quick access to pot files. How many clicks you need to > do that? If it's more than one after visiting the page from your > favorite bar, there is something like click/bandwidth/time, that can > be improved, right? > > Translation by itself is an individual project and has nothing to do > with the git or svn. > > How many times did you "correct" a single word, that was not syncd in > many translations? Last time I did that I had to "repair" 17 files. > Why carry apple by apple from the market if you can take a basket with > you. If you need more than one line in svn/git or one click on the > website more than it's necessary, there is space for improvement, > rignt. Getting the files up and down should mean NO effort. It should > be easier then ftp-ing them to some server. The real work, with all > the logging and diffing, crediting, upgrading and stuff should start > from that point on. > > The last maintainer quit being a mantainer, because he had no time. > The last zip that I sent him for 2.22 some time ago had 83 upgraded > files. If someone sends me 83 files to commit, I'd break down and cry > ... > > Then I'd start again yelling about SINGLE FOLDER for one language. > Less time needed, less bandwidth, less clicks, less nerves, more > translating and proofing. A winning situation. Hi Matej, Earlier in this thread I mention a possible way to have all translations for each language in its own repository (thus, single folder). There where some advantages and disadvantages with this process. I am not sure if you managed to try it using the test repositories from github.com. I believe there is a potential to adapt the proposal so that the disadvantages are eliminated. If you want to have a look at it, it would be great. I'ld be happy to discuss about it. An alternative to the initial proposal of this thread would be to get damned-lies to allow to commit many translation files, as described in the other thread. The bug report is http://bugzilla.gnome.org/show_bug.cgi?id=568295 Simos > On Tue, Jan 20, 2009 at 4:55 PM, Kenneth Nielsen > wrote: >> 2009/1/19 Matej Urban : >>> Thanks, Gil, >>> >>> I will wait and see, but since I'm a translator/mantainer and since I >>> doubt I will be able to upload many files at once, the only difference >>> so far I see, is that I will replace keyboard keystrokes for mouse >>> clicks. There will be no changelog, which is an improvement :) >> >> I don't see how this solution will NOT improve your situation. When >> you want to commit you just have to upload a file via a web-interface. >> Which means that you cut both space and bandwitdth down to a minimum, >> the only thing left is time. You do save the time it takes out to >> check out the modules and fill out the ChangeLog, but you do not get >> to save the time you could if you could commit more files at once. But >> in my opinion that should never be made a possibility (and I'm a >> translation coordinator not a developer), you use verision control >> systems (of any kind) to track changes, which makes it easy to revert >> if you do something wrong, but that hardly makes sense if you commit >> very large changes. >> >> Regards Kenneth >> >> PS: I have a commit script I can send you if you want to use it in the >> meantime, but let me know only if you want to use it as I would have >> to nicefy it a bit before ot could be used by others. >> >>> >>> Anyhow, in the end I will use whatever I'll need to do it, but keep >>> nagging about it. For some reason, I really doubt that single dir for >>> all po files, is a big programing deal. No obsolete clicks, no hassle, >>> just pure translation work. >>> >>> Matej >>> >>> On Mon, Jan 19, 2009 at 1:46 PM, Gil Forcada wrote: Hi, Actually a lot has changed: - for advanced-translators the same workflow will be maintained. - for plain translators a web interface to commit languages will be provided. So I think you fall in the second option and thus you will need to have access to http://l10n.gnome.org to download updated po files (like you can do right know), track its status (like as of January you can do right now) and commit them in source repositories (like you will be able to do in a not-so-distant-future, Claude said it has a beta working version that does this, I'm right Claude?) So, all in all, your workflow will
Re: Using Git and separating translations into their own l10n-LL repository
On Wed, Jan 21, 2009 at 4:20 AM, Simos Xenitellis wrote: > On Wed, Jan 21, 2009 at 8:27 AM, Matej Urban wrote: >> Well, I'm sure the devels are able to make the system work in anyway >> they choose, that's why I yell so loudly to get all the po files of >> one language into one single directory. Now that would cut down the >> maintenance. > > Earlier in this thread I mention a possible way to have all > translations for each language in its own repository (thus, single > folder). There where some advantages and disadvantages with this > process. I am not sure if you managed to try it using the test > repositories from github.com. > I believe there is a potential to adapt the proposal so that the > disadvantages are eliminated. > If you want to have a look at it, it would be great. I'ld be happy to > discuss about it. Given the number of times that translators have broken the build of our module, Gnome Games, because they don't run make check before they commit. I'm 100% opposed to any configuration in which translators are freed from the responsibility of making sure that they didn't break something. Both of these proposals are good ideas but will cause many headaches unless the make check is automated somehow. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [Fwd: [Bug 566454] Literal values should be kept between double quotes]
On Tue, Jan 20, 2009 at 05:59:49PM -0200, Leonardo F. Fontenelle wrote: > Em Seg, 2009-01-19 às 23:20 +0100, Andre Klapper escreveu: > > Am Montag, den 19.01.2009, 20:09 -0200 schrieb Leonardo F. Fontenelle: > > > If devhelp branch gnome-2-24 is used in GNOME 2.26, is it still string > > > freezed? > > > > yes, it is still string frozen and will remain for all times, because > > the gnome-2-24 branch is also used in the stable GNOME 2.24 series which > > is string frozen too. > > > > The following diff in the POT shows what I changed in the source code > for trunk. I'm posting here to warn translators to check if the > translations in GNOME 2.24 are correct. The elements names shouldn't be > translated! Then, why are those elements just a part of the msgid without a translation comment? Please either add a translation comment or use %s instead of the untranslatable element. Thanks. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | |jabber: mar...@jabber.sk | +---+ ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String change in Nautilus
2009-01-21 klockan 03:12 skrev A. Walton:
> We fixed a misspelled word ("progam"->"program") in Trunk.
Note that sometimes you can also update the translations automatically with
a carefully crafted "sed" line that only changes the relevant msgid lines.
Always check the diff before committing so that you know for sure no
translated text is mangled.
— Wouter
signature.asc
Description: Digital signature
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
If damned-lies is able to commit files it will be "trivial" (Claude?) to first check that the dist check is ok. Cheers, El dc 21 de 01 de 2009 a les 10:31 -0600, en/na Jason D. Clinton va escriure: > On Wed, Jan 21, 2009 at 4:20 AM, Simos Xenitellis > wrote: > > On Wed, Jan 21, 2009 at 8:27 AM, Matej Urban wrote: > >> Well, I'm sure the devels are able to make the system work in anyway > >> they choose, that's why I yell so loudly to get all the po files of > >> one language into one single directory. Now that would cut down the > >> maintenance. > > > > Earlier in this thread I mention a possible way to have all > > translations for each language in its own repository (thus, single > > folder). There where some advantages and disadvantages with this > > process. I am not sure if you managed to try it using the test > > repositories from github.com. > > I believe there is a potential to adapt the proposal so that the > > disadvantages are eliminated. > > If you want to have a look at it, it would be great. I'ld be happy to > > discuss about it. > > Given the number of times that translators have broken the build of > our module, Gnome Games, because they don't run make check before they > commit. I'm 100% opposed to any configuration in which translators are > freed from the responsibility of making sure that they didn't break > something. > > Both of these proposals are good ideas but will cause many headaches > unless the make check is automated somehow. > ___ > gnome-i18n mailing list > gnome-i18n@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-i18n -- gil forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
Le mercredi 21 janvier 2009 à 10:31 -0600, Jason D. Clinton a écrit : > On Wed, Jan 21, 2009 at 4:20 AM, Simos Xenitellis > wrote: > > On Wed, Jan 21, 2009 at 8:27 AM, Matej Urban wrote: > >> Well, I'm sure the devels are able to make the system work in anyway > >> they choose, that's why I yell so loudly to get all the po files of > >> one language into one single directory. Now that would cut down the > >> maintenance. > > > > Earlier in this thread I mention a possible way to have all > > translations for each language in its own repository (thus, single > > folder). There where some advantages and disadvantages with this > > process. I am not sure if you managed to try it using the test > > repositories from github.com. > > I believe there is a potential to adapt the proposal so that the > > disadvantages are eliminated. > > If you want to have a look at it, it would be great. I'ld be happy to > > discuss about it. > > Given the number of times that translators have broken the build of > our module, Gnome Games, because they don't run make check before they > commit. I'm 100% opposed to any configuration in which translators are > freed from the responsibility of making sure that they didn't break > something. > > Both of these proposals are good ideas but will cause many headaches > unless the make check is automated somehow. I suppose you're talking about documentation translation, right? Because for ui translation, I don't see how to break the build when the file pass msgfmt -vc (as required by the SVN hook). For doc translation, yes, damned-lies could be enhanced to build the documentation from the translations and check the result with xmllint. Feel free to add a bug report about this. But this has nothing to do with the location of files in the VCS. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Git and separating translations into their own l10n-LL repository
On Wed, Jan 21, 2009 at 11:31 AM, Claude Paroz wrote: >> Given the number of times that translators have broken the build of >> our module, Gnome Games, because they don't run make check before they >> commit. I'm 100% opposed to any configuration in which translators are >> freed from the responsibility of making sure that they didn't break >> something. >> >> Both of these proposals are good ideas but will cause many headaches >> unless the make check is automated somehow. > > I suppose you're talking about documentation translation, right? Because > for ui translation, I don't see how to break the build when the file > pass msgfmt -vc (as required by the SVN hook). Yep. > For doc translation, yes, damned-lies could be enhanced to build the > documentation from the translations and check the result with xmllint. > Feel free to add a bug report about this. But this has nothing to do > with the location of files in the VCS. I didn't say that it did. It seems like any change that frees translators from the ability to run xmllint and claim they were just following the approved workflow should be considered a regression. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[Fwd: New module decisions for 2.26]
FYI. --- Begin Message --- Hi, The release team met on Sunday to talk about the latest movies, the forthcoming Australian Open, etc. but also to make fun of Andreas N. (we won't reveal his last last name publicly -- but he's swedish and draws various things). Hopefully, Andreas N. didn't notice that and he will continue to be helpful :-) Oh, we also discussed the new modules proposals and came to the following result. Many thanks to the people who contributed to the discussion on the list, and to the authors and maintainers of the proposed modules! Short summary = In: brasero (desktop suite) evolution-mapi (desktop suite) gnome-user-share (desktop suite) DeviceKit-power (external dependency) farsight2 (external dependency) libgda (external dependency) libical (external dependency) libmapi (external dependency) libnotify (external dependency) libproxy (external dependency) Mono.Addins (external dependency) pulseaudio (external dependency) unique (external dependency) Moved: intltool (from platform to external dependency) Out: libseed WebKit/GTK+ Out, but because they are not external dependencies strictly speaking: notification-daemon samba4 Removed: gnome-volume-manager (replaced by nautilus, etc.) nautilus-cd-burner (replaced by brasero) Details === + brasero (desktop) - mixed feelings in the community and in the release team - reactive development team - directly conflicts with nautilus-cd-burner feature-wise, so if accepted, nautilus-cd-burner has to be deprecated - fills a need that has been felt by many users - used by default on several distributions already => approved => nautilus-cd-burner is therefore deprecated + DeviceKit-power (external dependency) - needed for the new gnome-power-manager => approved + evolution-mapi (desktop) - depends on libmapi, which depends samba4 - libmapi 0.8.0 will be released in the next few days - provides support for exchange 2007 (which evolution-exchange doesn't do) - some features might not be ready for 2.26 (Password Expiry, Send Options, Out-of-Office) - possible to choose between evolution-exchange and evolution-mapi at runtime => approved We'll keep evolution-exchange in 2.26 if possible, to avoid regressions for people who do not require exchange 2007 support. + farsight 2 (external dependency) - needed for empathy - will make it possible to offer good VoIP support => approved + gnome-user-share (desktop) - no documentation - Bastien wants one capplet to cover vino & gnome-user-share preferences (would live in gnome-control-center). This is not required for 2.26, but would still be nice if possible. - hard depends on libnotify, but looks easy to make this dependency optional. => approved Even though this was not a blocker, the release team would like to see some effort towards writing documentation. + libgda (external dependency) - needed for anjuta - mixed about libgda vs sqlite: some release team people feel that anjuta needs would be satisfied with sqlite which is already an external dependency - the symbol db plugin could be optional - switching anjuta to sqlite probably requires some non-negligible effort => approved It'd be nice to have someone write a small wiki page to help people choose between libgda and sqlite. + libical (external dependency) - needed to remove the fork from evolution-data-server - less duplication is good => approved + libmapi (external dependency) - needed for evolution-mapi - see evolution-mapi rationale => approved + libnotify (external dependency) - widely used - would be nice to have a more active development - feature that should live in GTK+ in the future (when dbus can be used there) => approved The release team wants to stress out that it should really not be abused (as it tends to be). + libproxy (external dependency) - needed for libsoup => approved + libseed (external dependency) - one game in gnome-games uses it - too early to know how used it will be, and how the community reacts from a libseed vs gjs point of view - good to see libseed and gjs developers talk about making things compatible => rejected + Mono.Addins (external dependency) - needed to remove the version bundled with tomboy - less duplication is good => approved + notification-daemon (external dependency) - not really a build-time dependency, so not strictly needed - still use libsexy - would be nice to have a more active development - would be nice to see the new development going on after the discussion in December - libnotify has API to detect the capabilities of a running notification daemon => rejected, but because it's orthogonal to our external dependencies (it's like apache fo
Re: New module decisions for 2.26
Thanks for the notice, l10n.gnome.org has been updated. Claude Le mercredi 21 janvier 2009 à 19:20 +0100, Vincent Untz a écrit : > Hi, > > The release team met on Sunday to talk about the latest movies, the > forthcoming Australian Open, etc. but also to make fun of Andreas N. (we > won't reveal his last last name publicly -- but he's swedish and draws > various things). Hopefully, Andreas N. didn't notice that and he will > continue to be helpful :-) Oh, we also discussed the new modules > proposals and came to the following result. > > Many thanks to the people who contributed to the discussion on the list, > and to the authors and maintainers of the proposed modules! > > > Short summary > = > > In: > brasero (desktop suite) > evolution-mapi (desktop suite) > gnome-user-share (desktop suite) > DeviceKit-power (external dependency) > farsight2 (external dependency) > libgda (external dependency) > libical (external dependency) > libmapi (external dependency) > libnotify (external dependency) > libproxy (external dependency) > Mono.Addins (external dependency) > pulseaudio (external dependency) > unique (external dependency) > > Moved: > intltool (from platform to external dependency) > > Out: > libseed > WebKit/GTK+ > > Out, but because they are not external dependencies strictly speaking: > notification-daemon > samba4 > > Removed: > gnome-volume-manager (replaced by nautilus, etc.) > nautilus-cd-burner (replaced by brasero) > > > Details > === > > + brasero (desktop) >- mixed feelings in the community and in the release team >- reactive development team >- directly conflicts with nautilus-cd-burner feature-wise, so if > accepted, nautilus-cd-burner has to be deprecated >- fills a need that has been felt by many users >- used by default on several distributions already >=> approved >=> nautilus-cd-burner is therefore deprecated > > + DeviceKit-power (external dependency) >- needed for the new gnome-power-manager >=> approved > > + evolution-mapi (desktop) >- depends on libmapi, which depends samba4 >- libmapi 0.8.0 will be released in the next few days >- provides support for exchange 2007 (which evolution-exchange > doesn't do) >- some features might not be ready for 2.26 (Password Expiry, Send > Options, Out-of-Office) >- possible to choose between evolution-exchange and evolution-mapi at > runtime >=> approved > We'll keep evolution-exchange in 2.26 if possible, to avoid > regressions for people who do not require exchange 2007 support. > > + farsight 2 (external dependency) >- needed for empathy >- will make it possible to offer good VoIP support >=> approved > > + gnome-user-share (desktop) >- no documentation >- Bastien wants one capplet to cover vino & gnome-user-share > preferences (would live in gnome-control-center). This is not > required for 2.26, but would still be nice if possible. >- hard depends on libnotify, but looks easy to make this dependency > optional. >=> approved > Even though this was not a blocker, the release team would like to > see some effort towards writing documentation. > > + libgda (external dependency) >- needed for anjuta >- mixed about libgda vs sqlite: some release team people feel that > anjuta needs would be satisfied with sqlite which is already an > external dependency >- the symbol db plugin could be optional >- switching anjuta to sqlite probably requires some non-negligible > effort >=> approved > It'd be nice to have someone write a small wiki page to help > people choose between libgda and sqlite. > > + libical (external dependency) >- needed to remove the fork from evolution-data-server >- less duplication is good >=> approved > > + libmapi (external dependency) >- needed for evolution-mapi >- see evolution-mapi rationale >=> approved > > + libnotify (external dependency) >- widely used >- would be nice to have a more active development >- feature that should live in GTK+ in the future (when dbus can be > used there) >=> approved > The release team wants to stress out that it should really not be > abused (as it tends to be). > > + libproxy (external dependency) >- needed for libsoup >=> approved > > + libseed (external dependency) >- one game in gnome-games uses it >- too early to know how used it will be, and how the community reacts > from a libseed vs gjs point of view >- good to see libseed and gjs developers talk about making things > compatible >=> rejected > > + Mono.Addins (external dependency) >- needed to remove the version bundled with tomboy >- less duplication is good >=> approved > > + notification-daemon (external dependency) >- not really a build-time d
Re: gtk+ r22164 - in trunk: . gtk
[CC: gnome-i18n]
Hi Matthias,
See below.
2009-01-21 klockan 21:09 skrev matthi...@svn.gnome.org:
> Modified: trunk/gtk/gtkentry.c
> ==
> --- trunk/gtk/gtkentry.c (original)
> +++ trunk/gtk/gtkentry.c Wed Jan 21 20:09:49 2009
> @@ -9598,17 +9597,8 @@
>
>if (!entry->visible && priv->caps_lock_warning)
> {
> - gboolean capslock_on;
> - gboolean im_on;
> -
> - capslock_on = gdk_keymap_get_caps_lock_state (keymap);
> - im_on = g_strcmp0 (gtk_im_multicontext_get_context_id
> (GTK_IM_MULTICONTEXT (entry->im_context)), "gtk-im-context-simple") != 0;
> - if (capslock_on && im_on)
> -text = _("You have the Caps Lock key on\nand an active input
> method");
> - else if (capslock_on)
> + if (gdk_keymap_get_caps_lock_state (keymap))
> text = _("You have the Caps Lock key on");
> - else if (im_on)
> -text = _("You have an active input method");
> }
Can this string perhaps be changed to not address users directly by avoiding
"you"? This sounds unfriendly to unknowing users (what did I do wrong?), and
is even considered bad form in some cultures. Furthermore, a caps lock key
cannot be "on": either *caps lock* is on, or the *caps lock key* has been
pressed. Suggested string change: "Caps Lock is on."
— Wouter
signature.asc
Description: Digital signature
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [Fwd: [Bug 566454] Literal values should be kept between double quotes]
Em Qua, 2009-01-21 às 17:35 +0100, Marcel Telka escreveu: > On Tue, Jan 20, 2009 at 05:59:49PM -0200, Leonardo F. Fontenelle wrote: > > Em Seg, 2009-01-19 às 23:20 +0100, Andre Klapper escreveu: > > > Am Montag, den 19.01.2009, 20:09 -0200 schrieb Leonardo F. Fontenelle: > > > > If devhelp branch gnome-2-24 is used in GNOME 2.26, is it still string > > > > freezed? > > > > > > yes, it is still string frozen and will remain for all times, because > > > the gnome-2-24 branch is also used in the stable GNOME 2.24 series which > > > is string frozen too. > > > > > > > The following diff in the POT shows what I changed in the source code > > for trunk. I'm posting here to warn translators to check if the > > translations in GNOME 2.24 are correct. The elements names shouldn't be > > translated! > > Then, why are those elements just a part of the msgid without a > translation comment? Please either add a translation comment or use %s > instead of the untranslatable element. > Words between double quotes are usually literal values, but if it's not clear enough already, comments shouldn't hurt. (Richard Hult, please do it; my right forearm hurts and I'm typing just with the other hand.) We've discussed the %s here, weeks or months ago. Keeping the literal values helps the translator choosing gender and other inflexion in the remaining translation, and allows the translation to have explanations like: "Os valores válidos são \"none\" (nenhum), \"top\" (topo)..." -- Leonardo Fontenelle http://leonardof.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
GTK+ string change
Hey, I have just removed two strings from GTK+: You have the Caps Lock key on\nand an active input method You have an active input method (since it turns out that warning about active input methods is not really workable in some locales...) and changed the third one to be more neutral (at the request of Wouter Bolsterlee): You have the Caps Lock key on is now Caps Lock is on Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Update scratchbox plugin in Anjuta
Hi, I have updated the scratchbox plugin in Anjuta, so a few strings have been changed in plugins/scratchbox/anjuta-scratchbox.glade. Regards, Sébastien ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [Fwd: New module decisions for 2.26]
El mié, 21-01-2009 a las 19:55 +0100, Andre Klapper escribió: > + gnome-user-share (desktop) >- no documentation hum, that's already fixed, isn't it? Cheers. -- Jorge González González Weblog: http://aloriel.no-ip.org Fotolog: http://www.flickr.com/photos/aloriel ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Translation of sawfish
Hi all, I just wanted to ask, if you'll also translate sawfish. (1.5.0 is scheduled for this sommer and there have been major changes, which broke a lot of strings). You are free to do any change to sawfish, which helps you in managing translations. Thanks in advance, Chris signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String change in Nautilus
On Wed, Jan 21, 2009 at 11:40 AM, Wouter Bolsterlee wrote:
> 2009-01-21 klockan 03:12 skrev A. Walton:
>> We fixed a misspelled word ("progam"->"program") in Trunk.
>
> Note that sometimes you can also update the translations automatically with
> a carefully crafted "sed" line that only changes the relevant msgid lines.
> Always check the diff before committing so that you know for sure no
> translated text is mangled.
Fixed this in trunk. Thanks for the heads up Wouter.
-A. Walton
>
>— Wouter
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: This message was signed/encrypted using GnuPG.
>
> iD8DBQFJd1ARP7QTTiUKY+sRArMHAKDBdBZVV/n/FPrYWCIAXOTgBDWQjwCeJ75H
> kgEOGXt3o5IyKmJY/ruLdGA=
> =Jz/9
> -END PGP SIGNATURE-
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
String changes in gnome-keyring
gnome-keyring had string additions in gcr-importer.c Cheers, Stef Walter ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
