nautilus-open-terminal 0.10 release imminent (was: nautilus-open-terminal 0.10 release soon)
Dear translators, I will do a release on Sunday, 2009-04-12. Please update your translations if you haven't done so already. best regards, Christian Neumair Am Montag, den 09.03.2009, 14:16 +0100 schrieb Christian Neumair: After the release of GNOME 2.26, there will be a nautilus-open-terminal 0.10 release. Additions since 0.9: Open in Local Terminal Open in Remote Terminal Changes since 0.9: Open Terminal Open in Terminal * changed accelerator to e [due to conflict with New Tab] * made in lower case. best regards, Christian Neumair -- Christian Neumair cneum...@gnome.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
nautilus-open-terminal 0.10 release soon
After the release of GNOME 2.26, there will be a nautilus-open-terminal 0.10 release. Additions since 0.9: Open in Local Terminal Open in Remote Terminal Changes since 0.9: Open Terminal Open in Terminal * changed accelerator to e [due to conflict with New Tab] * made in lower case. best regards, Christian Neumair -- Christian Neumair cneum...@gnome.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
plural forms for counting “composed” numbers: “3 hours, 2 minutes remain(s)”?
Feel free to skim over this message, but just want to know where you can help as a translator with a non-english mother tongue. Your feedback is important for solving the Nautilus translation bug 551222 [1]. 1. Where YOU can help us In your mother tongue, in the sentence “3 hours, 2 minutes remain(s)” do you decide which verb form (i.e. plural form) to use for “remain” based on A. the SUM of hours and minutes B. ONLY the hours C. ONLY the minutes? In English, Spanish, Italian and German we just A., i.e. the sum. However, these languages are special in that we just have two plural forms N=1, N!=1, so in this case the plural would always be used. On the other there are very complex plural forms in some languages (for instance in Russian). 2. Some background == As you may know, in many languages (including English) there are participle constructions. In this concrete example, we consider how the remaining time of a file operation (download, etc.) can be specified like: 3 hours, 2 minutes remaining 1 minute remaining. We actually use “... left” in Nautilus, but we will consider analogies to a verb so remaining is used: Some languages have a plural-sensitive participle, in analogy to 3 hours, 2 minutes remain 1 minute remains. Consider italian, where we have 3 ore, 2 minuti remanenti (plural) 1 minuto rimanente (singular) even in the participle case. Now the big question is: What plural forms are supposed to be used in this context? Obviously in all languages, if only hours and minutes are displayed, we can apply the “normal” ngettext() rules: ngettext (%d hour remaining, %d hours remaining, number_of_hours); or ngettext (%d minute remaining, %d minutes remaining, number_of_minutes); and everything would be correct in any language, assuming the correct plural forms and translations are set up. However, now let's consider the tricky case where both of them are displayed: H = ngettext (%d hour, %d hours, number_of_hours); M = ngettext (%d minute, %d minutes, number_of_minutes); i.e. each of the nouns is declined according to the number of the objects. Now the composed string “3 hours, 2 minutes remaining”: ngettext (A, B remaining, /* singular, i.e. remain */ A, B remaining, /* plural, i.e. remains */ ???); The big question is how the ??? would look like. We have three basic possibilities: ??? = number_of_hours ??? = number_of_minutes ??? = number_of_hours + number_of_minutes I know that for some Middle and Southern European languages (at least Italian, Spanish and German), we count both the hours and the minutes as distinct objects and add them up, as specified under 1. (hours + minutes 1) = remanenti, verbleiben else = rimenente, verbleibt That said, ??? = number_of_minutes + number_of_hours. i.e. whenever there are one or more hour and one or more minute remaining, the plural form is used. In other words, we always use the plural form in the composed case. Now the question is: What do we do in a fictive language where N=1 = form 1 N=5 = form 2 else = form 3 A similar structure is at least used for Russian. Assuming we apply the rule above, in the example 3 hours, 2 minutes remaining we have N=3 (hours) + 2 (minutes) = 5 N=5 = form 2 Is that rule actually correct for all languages? (cf. section 1.) best regards, Christian Neumair [1] http://bugzilla.gnome.org/show_bug.cgi?id=551222 -- Christian Neumair [EMAIL PROTECTED] ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Status of gnome-menu-editor
Am Dienstag, den 28.03.2006, 14:04 +0200 schrieb Luca Ferretti: a little question from Italian GNOME Team: is g-m-e still maintained? Or we can simply ignore it and go to translate other stuff? I've CCed gnome-i18n to inform other translators. While it is unmaintained (yet fully functional), I don't think the question is really valid. The package is in the other section and just has 23 strings. I used to only translate other packages when I used them - shouldn't you in general skip the boring ones? :) -- Christian Neumair [EMAIL PROTECTED] 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
tooltips are also strings (was: Re: Nautilus: string/UI freeze approval request)
On Fri, 2006-02-17 at 18:20 +0100, Danilo Šegan wrote: Today at 16:44, Christian Neumair wrote: Proposed modifications * Add new UI items for mounting/ejecting/unmounting/formatting volumes, marked for translation, displayed in the file menu, background context and location button/label context menu if applicable. * Reorder tree view context menu Properties and Unmount entries to fit to with the newly-introduced order. Alexander is concerned that this may invalidate previously taken screenshots. Why wasn't it possible to do this prior to string freeze? If it amounted to these 8 new strings in the string freeze which add a new feature at the same time, it'd be a no from me regarding i18n :) But: - _Eject, _Format, _Mount Volume, _Unmount Volume already exist in Nautilus (same file, even), so they are not under string freeze - tooltips don't really bring much value I'd say, and you can reuse the values for the above (instead of ... volume associated with the open folder use the existing ... selected volume), and later fix it once you branch for 2.14 So, a reminder: if a string already exists among translatable module messages, you need not ask GTP for string freeze break. More details on http://live.gnome.org/TranslationProject/HandlingStringFreezes It's up to developers to take advantage of this trick and look at their POT files to see what messages already exist :) I used to be a translator for three years, so I'm aware of that fact, and I didn't reuse the old strings by accident. However, I'm introducing new tooltips which fall into the definition of new strings, so approval is needed, at least that's how I interpret our rules. -- Christian Neumair [EMAIL PROTECTED] 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
Nautilus: string/UI freeze approval request
The attached patch adds support to Nautilus for ejecting unmounting
volumes from within the target directory. It was already approved by
Alexander Larsson [1], and requires string and UI freeze breakage
approval.
Proposed modifications
* Add new UI items for mounting/ejecting/unmounting/formatting volumes,
marked for translation, displayed in the file menu, background context
and location button/label context menu if applicable.
* Reorder tree view context menu Properties and Unmount entries to
fit to with the newly-introduced order. Alexander is concerned that this
may invalidate previously taken screenshots.
[1]
http://mail.gnome.org/archives/nautilus-list/2006-February/msg00087.html
--
Christian Neumair [EMAIL PROTECTED]
Index: src/file-manager/fm-actions.h
===
RCS file: /cvs/gnome/nautilus/src/file-manager/fm-actions.h,v
retrieving revision 1.10
diff -u -p -r1.10 fm-actions.h
--- src/file-manager/fm-actions.h 12 Dec 2005 16:59:11 - 1.10
+++ src/file-manager/fm-actions.h 17 Feb 2006 14:19:16 -
@@ -60,6 +60,10 @@
#define FM_ACTION_UNMOUNT_VOLUME Unmount Volume
#define FM_ACTION_EJECT_VOLUME Eject Volume
#define FM_ACTION_FORMAT_VOLUME Format Volume
+#define FM_ACTION_SELF_MOUNT_VOLUME Self Mount Volume
+#define FM_ACTION_SELF_UNMOUNT_VOLUME Self Unmount Volume
+#define FM_ACTION_SELF_EJECT_VOLUME Self Eject Volume
+#define FM_ACTION_SELF_FORMAT_VOLUME Self Format Volume
#define FM_ACTION_SCRIPTS Scripts
#define FM_ACTION_NEW_DOCUMENTS New Documents
#define FM_ACTION_NEW_EMPTY_FILE New Empty File
Index: src/file-manager/fm-directory-view.c
===
RCS file: /cvs/gnome/nautilus/src/file-manager/fm-directory-view.c,v
retrieving revision 1.734
diff -u -p -r1.734 fm-directory-view.c
--- src/file-manager/fm-directory-view.c 26 Jan 2006 22:20:59 - 1.734
+++ src/file-manager/fm-directory-view.c 17 Feb 2006 14:19:21 -
@@ -75,6 +75,7 @@
#include libgnomevfs/gnome-vfs-result.h
#include libgnomevfs/gnome-vfs-uri.h
#include libgnomevfs/gnome-vfs-utils.h
+#include libgnomevfs/gnome-vfs-volume-monitor.h
#include libnautilus-private/nautilus-recent.h
#include libnautilus-extension/nautilus-menu-provider.h
#include libnautilus-private/nautilus-clipboard-monitor.h
@@ -385,6 +386,9 @@ static gboolean activate_check_mime_type
gboolean warn_on_mismatch);
static GdkDragAction ask_link_action (FMDirectoryView *view);
+static void file_get_volume_and_drive (NautilusFile*file,
+ GnomeVFSVolume **volume,
+ GnomeVFSDrive **drive);
static void action_open_scripts_folder_callback(GtkAction *action,
gpointer callback_data);
@@ -6286,6 +6290,111 @@ action_eject_volume_callback (GtkAction
}
static void
+action_self_mount_volume_callback (GtkAction *action,
+ gpointer data)
+{
+ NautilusFile *file;
+ GnomeVFSDrive *drive;
+ FMDirectoryView *view;
+
+ view = FM_DIRECTORY_VIEW (data);
+
+ file = fm_directory_view_get_directory_as_file (view);
+ if (file == NULL) {
+ return;
+ }
+
+ file_get_volume_and_drive (file, NULL, drive);
+
+ if (drive != NULL) {
+ gnome_vfs_drive_mount (drive, drive_mounted_callback, NULL);
+ }
+
+ gnome_vfs_drive_unref (drive);
+}
+
+static void
+action_self_unmount_volume_callback (GtkAction *action,
+ gpointer data)
+{
+ NautilusFile *file;
+ GnomeVFSVolume *volume;
+ GnomeVFSDrive *drive;
+ FMDirectoryView *view;
+
+ view = FM_DIRECTORY_VIEW (data);
+
+ file = fm_directory_view_get_directory_as_file (view);
+ if (file == NULL) {
+ return;
+ }
+
+ file_get_volume_and_drive (file, volume, drive);
+
+ if (volume != NULL) {
+ gnome_vfs_volume_unmount (volume, volume_or_drive_unmounted_callback, NULL);
+ } else if (drive != NULL) {
+ gnome_vfs_drive_unmount (drive, volume_or_drive_unmounted_callback, NULL);
+ }
+
+ gnome_vfs_volume_unref (volume);
+ gnome_vfs_drive_unref (drive);
+}
+
+static void
+action_self_eject_volume_callback (GtkAction *action,
+ gpointer data)
+{
+ NautilusFile *file;
+ GnomeVFSDrive *drive;
+ GnomeVFSVolume *volume;
+ FMDirectoryView *view;
+
+ view = FM_DIRECTORY_VIEW (data);
+
+ file = fm_directory_view_get_directory_as_file (view);
+ if (file == NULL) {
+ return;
+ }
+
+ file_get_volume_and_drive (file, volume, drive);
+
+ if (volume != NULL) {
+ gnome_vfs_volume_eject (volume, volume_or_drive_unmounted_callback, NULL);
+ } else if (drive != NULL) {
+ gnome_vfs_drive_eject (drive, volume_or_drive_unmounted_callback, NULL);
+ }
+
+ gnome_vfs_volume_unref (volume);
+ gnome_vfs_drive_unref (drive);
+}
+
+static void
+action_self_format_volume_callback (GtkAction *action,
+gpointer data)
+{
+ NautilusFile *file;
+ GnomeVFSDrive *drive;
+ FMDirectoryView *view;
+
+ view = FM_DIRECTORY_VIEW (data);
+
+ file = fm_directory_view_get_directory_as_file (view);
+ if (file == NULL) {
+ return
Re: [PATCH] Freeze breakage: Fix URI activation cancellation for panel
Am Dienstag, den 18.10.2005, 18:29 +0200 schrieb Vincent Untz: Le vendredi 14 octobre 2005 à 16:51 +0200, Christian Neumair a écrit : The attached patches are meant to fix cancellation of URI activations through the panel. Also, if you don't want to break UI freeze, you can choose to not mark the new string as translatable. But it can probably wait for 2.13, can't it? Now that I read the release-team policies again, you are right that it doesn't fit into the release critical category. But it's a bug a notable percentage of our users experiences. So I'm ready to withdraw this request if anybody is against it, but still would love to get it in. -- Christian Neumair [EMAIL PROTECTED] 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: [PATCH] Freeze breakage: Fix URI activation cancellation for panel
Am Montag, den 17.10.2005, 10:20 +0200 schrieb Alexander Larsson:
On Fri, 2005-10-14 at 16:51 +0200, Christian Neumair wrote:
The attached patches are meant to fix cancellation of URI activations
through the panel. They are against libgnome, gnome-panel and gnome-vfs,
and break string freeze, and potentially even API freeze. I wonder
whether adding an element to a public enum is consiered an API change.
Life would have been easier if GnomeURLError used negative error codes,
reserving all = 0 for GnomeVFSResult retvals.
GnomeURLError was written before gnome_vfs_show_url existed...
I've also CCed random people that often occur in recent ChangeLogs of
the affected producs and/or released tarballs. MAINTAINERS files aren't
up to date for any of these.
The gnome-vfs patch should really modify _gnome_vfs_get_slow_mime_type()
(it is the only used for this function) instead of copying it into the
function.
Yes, I know. I just didnt want to change that header. You reminded me
that even private API deserves some attention. Attaching a new patch
set.
What do you propose to resolve the
gnome_vfs_get_mime_type/_gnome_vfs_get_slow_mime_type signature
inconsistency the change introduces, considering that
_gnome_vfs_get_slow_mime_type is very likely to become public one day,
if not for GnomeVFS 2.14?
--
Christian Neumair [EMAIL PROTECTED]
Index: libgnome/gnome-url.c
===
RCS file: /cvs/gnome/libgnome/libgnome/gnome-url.c,v
retrieving revision 1.48
diff -u -p -r1.48 gnome-url.c
--- libgnome/gnome-url.c 28 Mar 2005 15:45:07 - 1.48
+++ libgnome/gnome-url.c 14 Oct 2005 14:30:32 -
@@ -120,7 +120,14 @@ gnome_url_show_with_env (const char *ur
GNOME_URL_ERROR_NOT_SUPPORTED,
_(The default action does not support this protocol.));
break;
-
+
+ case GNOME_VFS_ERROR_CANCELLED:
+ g_set_error (error,
+ GNOME_URL_ERROR,
+ GNOME_URL_ERROR_CANCELLED,
+ _(The request was cancelled.));
+ break;
+
default:
g_set_error (error,
GNOME_URL_ERROR,
Index: libgnome/gnome-url.h
===
RCS file: /cvs/gnome/libgnome/libgnome/gnome-url.h,v
retrieving revision 1.19
diff -u -p -r1.19 gnome-url.h
--- libgnome/gnome-url.h 25 Apr 2003 11:20:12 - 1.19
+++ libgnome/gnome-url.h 14 Oct 2005 14:30:32 -
@@ -42,7 +42,8 @@ typedef enum {
GNOME_URL_ERROR_URL,
GNOME_URL_ERROR_NO_DEFAULT,
GNOME_URL_ERROR_NOT_SUPPORTED,
- GNOME_URL_ERROR_VFS
+ GNOME_URL_ERROR_VFS,
+ GNOME_URL_ERROR_CANCELLED
} GnomeURLError;
#define GNOME_URL_ERROR (gnome_url_error_quark ())
Index: gnome-panel/panel-menu-items.c
===
RCS file: /cvs/gnome/gnome-panel/gnome-panel/panel-menu-items.c,v
retrieving revision 1.11
diff -u -p -r1.11 panel-menu-items.c
--- gnome-panel/panel-menu-items.c 9 Oct 2005 21:40:58 - 1.11
+++ gnome-panel/panel-menu-items.c 14 Oct 2005 14:35:50 -
@@ -39,6 +39,7 @@
#include glib/gi18n.h
#include libgnomevfs/gnome-vfs.h
+#include libgnome/gnome-url.h
#include libgnomeui/gnome-url.h
#include menu.h
@@ -102,16 +103,17 @@ activate_uri (GtkWidget *menuitem,
GNOME_VFS_MAKE_URI_DIR_HOMEDIR);
gnome_url_show_on_screen (url, screen, error);
- if (error) {
- escaped = g_markup_escape_text (url, -1);
- panel_error_dialog (screen, cannot_show_url, TRUE,
-_(Cannot display location '%s'),
-%s,
-escaped,
-error-message);
-
+ if (error != NULL) {
+ if (error-code != GNOME_URL_ERROR_CANCELLED) {
+ escaped = g_markup_escape_text (url, -1);
+ panel_error_dialog (screen, cannot_show_url, TRUE,
+ _(Cannot display location '%s'),
+ %s,
+ escaped,
+ error-message);
+ g_free (escaped);
+ }
g_error_free (error);
- g_free (escaped);
}
g_free (url);
}
Index: libgnomevfs/gnome-vfs-mime-private.h
===
RCS file: /cvs/gnome/gnome-vfs/libgnomevfs/gnome-vfs-mime-private.h,v
retrieving revision 1.10
diff -u -p -r1.10 gnome-vfs-mime-private.h
--- libgnomevfs/gnome-vfs-mime-private.h 27 Aug 2004 13:42:14 - 1.10
+++ libgnomevfs/gnome-vfs-mime-private.h 17 Oct 2005 19:15:40 -
@@ -41,7 +41,8 @@ gboolean _gnome_vfs_file_date_tr
void _gnome_vfs_mime_info_mark_gnome_mime_dir_dirty (void);
void _gnome_vfs_mime_info_mark_user_mime_dir_dirty (void);
-char * _gnome_vfs_get_slow_mime_type (const char *text_uri);
+GnomeVFSResult _gnome_vfs_get_slow_mime_type (const char *text_uri,
+ char **mime_type);
/* Should be exported, but we're in API freeze */
Index: libgnomevfs/gnome-vfs-mime.c
===
RCS file: /cvs/gnome/gnome-vfs/libgnomevfs/gnome-vfs-mime.c,v
retrieving revision 1.59
diff -u -p
Re: Some advice, please, on dealing with inappropriate comments
Am Samstag, den 20.08.2005, 09:49 +0200 schrieb Danilo Šegan: Ask developers to introduce another empty comment before the offending one. Isn't there a comment keyword that prevents comments from being sucked up by our greedy gettext? At least I vaguely remember that there is some mean to achieve this... . -- Christian Neumair [EMAIL PROTECTED] 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: Some queries and suggestions about bug reporting for PO files
Am Freitag, den 19.08.2005, 17:23 +0930 schrieb Clytie Siddall:
I've just come up for air after some long sessions in HEAD PO files,
and reported a _stack_ of typos etc. at Bugzilla,
Excellent!
and that's given rise to some irritation, um, constructive
suggestions in my mind. ;)
Event better!
1. Is the title of the PO file actually the name of the program as
listed in the Bugzilla pick a Gnome program list? For example, I
can't find a listing for uf-view or contact-lookup-applet.
These are not yet covered by bugzilla. For now, you should send your
suggestions to Bastien Nocera [EMAIL PROTECTED] for uf-view and to
Ross Burton [EMAIL PROTECTED] for contact-lookup-applet. Hopefully in
the long term bugzilla components will be added for those products.
Maybe you could ask them nicely, too? :)
2. If we are going to continue using Bugzilla for problems with PO
files, could we please ask each developer to choose the component
general for his or her program? When reporting typos or problems
with the PO file, being given the choice between applet and dæmon
is not useful.
We should IMHO rather add a localization component to gettextized
bugzilla products.
3. In fact, could we have a component named PO file or
translation, thus alerting the developer from the beginning to what
kind of report it is? Bugzilla is largely if not completely set up
for reports of difficulties _running_ a program, not with translating
its PO file. Having our own category would help both us and the
developers. It would help especially for Gnome Bug-Squashing Parties,
and Gnome Love Days, where translators could concentrate on bugs
reported under our category, if we wished, and achieve (even ;) )
more. Perhaps the i18n and l10n tags do this already, but I still
think it would help.
The product is called l10n [1]. Pretty cryptic, I must admit.
5. I reported the typo occured against four separate programs' PO
files today, and that's only _today's_ bug-reporting. This typo is a
disease at Gnome. Do we have any hope of immunizing our PO-file
developers? I thought it was a recent or isolated problem, when I
first encountered this typo in a few files, but it just keeps on
happening, and I've noticed at least one other translator saying he
has been trying to change this for some time. Is there, in fact, a
more efficient way to address a wide-spread type of error, other than
reporting it individually, again and again, against each and every PO
file which contains it?
You can bring up the issue on the desktop-devel-list mailing list [2] as
well, thus trying to attract developers' attention. Don't forget to
include listings of all affected software and links to your bug reports.
6. I would really like to make some sort of effective effort towards
increasing developers' awareness of the need for context. For
example, this string:
msgstr by {0}
No comment, no context, no nearby strings that appear to have any
connection with it at all. Good grief!
I reported this as a query, but I think we have to do far too much
guesswork while translating. How can we improve the situation? Is
there anything constructive and positive we can do?
I always had the advantage of being interested in source code and
application context. The first thing I did with a software I localized
is building it and grepping through the source code to find out what the
string is all about and in what context it appears. The string you talk
about is obviously from a C# software. They have this cracky {i}
construct instead of good-old (error prone ;P) C-style format
specifiers. It denotes that something will be inserted instead of the
{1}, probably an author's name or something. You can always rant at
programmers for not being i18n friendly, since almost all of them don't
spend a lot of attention to l10n details.
8. On the subject of repetitive work, I don't know much, if anything,
about the way Gnome system resources work, but do we really have to
translate things like Orientation, Orientation of the Tray,
File, Edit, Print and other extremely common if not ubiquitous
strings again and again in PO files?
IMHO we should really have shared GTK+ stock items for those extremely
common ones. The basic UI element descriptions should be constructed
inside the GTK+ library.
I'll bring this up on the GTK+ development list. Note that this will be
available downstream with GNOME 2.16 at earliest.
[1] http://bugzilla.gnome.org/enter_bug.cgi?product=l10n
[2] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
--
Christian Neumair [EMAIL PROTECTED]
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
Nautilus string change
A recent commit removed the msgid reset and introduced Reset. Thanks for your translation efforts! -- Christian Neumair [EMAIL PROTECTED] 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
gnome-menu-editor release imminent
I'd like to do a gnome-menu-editor release this weekend. You may want to update/add your translations now. Thanks for your efforts! :) -- Christian Neumair [EMAIL PROTECTED] ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[(RE)ANNOUNCING] nautilus-open-terminal
As you might remember, I once announced the release of nautilus-open-terminal [1], a nautilus extension for opening the terminal of a selected folder. Reinout van Schouwen, a diligent translator you might know, wanted to send me a translation update today and I noted that although I did only a leaky pre-release, package maintainers picked it up and packaged it, which was not intended at all, taken that I really didn't care for code quality. Thanks Reinout :). Because I lost the tarball and just didn't care what, I thought it would be lost, but it isn't: I was able to recover a kind-of-orignal tarball from the (pkg-alioth) debian repository and could resurrect it. I updated it to use a icon for the menu item and work for selected folders as well, not only for the currently open folder. And it has less crippled dependencies. Maybe now that it works it's really time to remove the Open Terminal item from the desktop context menu (Nautilus 2.12). Grab it from GNOME CVS (module: nautilus-open-terminal [2]) and start translating (3 strings)/testing :). Feedback is very much welcome. Have fun. [1] http://mail.gnome.org/archives/nautilus-list/2004-May/msg00022.html [2] http://cvs.gnome.org/viewcvs/nautilus-open-terminal -- Christian Neumair [EMAIL PROTECTED] ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
