Re: Issues with keyboard accelerators
Le lundi 30 mars 2009 à 22:28 +0100, Simos a écrit : [snip] I added the text at http://live.gnome.org/SimosXenitellis/KeyboardAcceleratorsAndAccents I did not see a canonical location on live.gnome.org to put the text. Where would it be good to move the page to? I'd suggest to add it as a new paragraph to the Localisation Guide. http://live.gnome.org/TranslationProject/LocalisationGuide There is a bullet in Other hints that talks about it already. You could merge it with your contents. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions to 'glib.master'
This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'glib.master': + (invalid encoding) + %.1f GB + %.1f KB + %.1f MB + %s filetype + %s type + (?R or (?[+-]digits must be followed by ) + ) without opening ( + An array containing the icon names + Association creation not supported on win32 + Attribute value must be non-NULL + Backup file creation failed + Can't copy directory over directory + Can't copy over directory + Can't copy special file + Can't create user MIME configuration folder %s: %s + Can't create user application configuration folder %s: %s + Can't create user desktop file %s + Can't find application + Can't handle the supplied version the icon encoding + Can't handle version %d of GEmblem encoding + Can't handle version %d of GEmblemedIcon encoding + Can't handle version %d of GFileIcon encoding + Can't handle version %d of GThemedIcon encoding + Can't move directory over directory + Can't open directory + Can't recursively copy directory + Can't rename file, filename already exist + Can't rename root directory + Cannot truncate GMemoryInputStream + Close file descriptor + Containing mount does not exist + Custom definition for %s + DEFINE group contains more than one branch + Desktop file didn't specify Exec field + Enumerator is closed + Error closing file: %s + Error closing unix: %s + Error creating backup copy: %s + Error creating directory: %s + Error getting filesystem info: %s + Error launching application: %s + Error making symbolic link: %s + Error moving file: %s + Error on line %d char %d: + Error opening file '%s': %s + Error opening file: %s + Error reading from file: %s + Error reading from unix: %s + Error removing file: %s + Error removing old backup link: %s + Error removing old file: %s + Error removing target file: %s + Error renaming file: %s + Error renaming temporary file: %s + Error seeking in file: %s + Error setting SELinux context: %s + Error setting extended attribute '%s': %s + Error setting owner: %s + Error setting permissions: %s + Error setting symlink: %s + Error setting symlink: file is not a symlink + Error stating file '%s': %s + Error stating file descriptor: %s + Error trashing file: %s + Error truncating file: %s + Error while compiling regular expression %s at char %d: %s + Error while matching regular expression %s: %s + Error while optimizing regular expression %s: %s + Error while parsing replacement text \%s\ at char %lu: %s + Error writing to file: %s + Error writing to unix: %s + Expected a GEmblem for GEmblemedIcon + Failed to resize memory output stream + Failed to write file '%s': fflush() failed: %s + Failed to write file '%s': fsync() failed: %s + File \%s\ is too large + File descriptor + File enumerator has outstanding operation + File enumerator is already closed + File names cannot contain '%c' + Filesystem root + Input stream doesn't implement read + Invalid GSeekType supplied + Invalid UTF-8 encoded text - not a start char + Invalid UTF-8 encoded text - not valid '%s' + Invalid UTF-8 encoded text - overlong sequence + Invalid attribute type (byte string expected) + Invalid attribute type (string expected) + Invalid attribute type (uint32 expected) + Invalid attribute type (uint64 expected) + Invalid extended attribute name + Invalid filename %s + Invalid filename + Invalid seek request + Invalid symlink value given + Malformed input data for GFileIcon + Malformed number of tokens (%d) in GEmblem encoding + Malformed number of tokens (%d) in GEmblemedIcon encoding + Malformed version number: %s + Memory output stream not resizable + Move between mounts not supported + No application is registered as handling this file + No type for class name %s + Odd character '%s', expected a '' character to end the empty-element tag '%s' + Operation not supported + Operation was cancelled + Output stream doesn't implement write + PCRE library is compiled without UTF8 properties support + PCRE library is compiled without UTF8 support + POSIX collating elements are not supported + POSIX named classes are supported only within a class + Reached maximum data array limit + SELinux context must be non-NULL + SELinux is not enabled on this system + Seek not supported on stream + Setting attribute %s not supported + Source stream is already closed + Stream doesn't support query_info + Stream has outstanding operation + Stream is already closed + Target file exists + Target file is
Re: Moving GLib and GTK+ to git
Le mardi 31 mars 2009 à 15:05 -0400, Matthias Clasen a écrit : 2009/3/31 Kristian Høgsberg k...@redhat.com: The glib and gtk+ repositories are up now and they are live: http://git.gnome.org/cgit/glib http://git.gnome.org/cgit/gtk+ [...] Other than that I'd say we're ready to go, but I'll leave it to Matthias to make the call. Thanks so much, Kristian! So yes, I think we are ready to go. I've updated l10n.gnome.org for both modules: http://l10n.gnome.org/module/glib http://l10n.gnome.org/module/gtk+ Do you know if the hook that send a mail to gnomeweb at gnome dot org at each commit has been ported to git? I am by no means a git master (that would be Kristian), so take what I am saying below with a grain of salt and correct me where necessary... Some things that we need to sort out include ChangeLog: The git way of doing things is to do small commits, with meaningful commit messages, and forego a separate ChangeLog file. Everybody who I talked to about this recommended going this way, so I'd say we should follow this. I'll add a final note to the current ChangeLog indicating this. Regarding the ChangeLog policy, it's important for translators to have a unified method throughout the GNOME modules. As it seems the majority of modules won't keep a manual ChangeLog with git (like you're proposing with glib and gtk+), I suggest to all translators to follow the indication on the Walkthrough for translators compiled by Simos, that is to use only the commit message. http://live.gnome.org/GitMigration/Translators Cheers, Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'glib.master'
Le mardi 31 mars 2009 à 19:23 +, GNOME Status Pages a écrit : This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'glib.master': + (invalid encoding) + %.1f GB + %.1f KB + %.1f MB snip Please ignore, this is a side effect of the git migration. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
On 03/31/2009 03:50 PM, David Zeuthen wrote: Personally I prefer non-capital and no periods; it makes the output of 'git log |git shortlog' nicer to look at (see [1] for an example) but maybe that's just me. I think capital letters would work nice here too; trailing periods would probably look weird though. While I prefer to capitalize sentence starters, NOT capitalizing makes it easier to start a commit summary with an API symbol name or other identifiers that should not be capitalized. behdad David [1] : David Zeuthen (198): [...] add some notes about terminology use the term Name instead of Label when creating a partition rework terminology for filesystem labels / partition labels fix compiler warnings introduced by the last set of patches add some experimental code for grid-based layout fix some criticals where we tried to access non-existant widgets rework partition table handling Matthias Clasen (13): HIG fixes trivial coding style fix avoid dialog resizing don't allow empty passphrases improved spacing for sections [...] ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
On Tue, 2009-03-31 at 15:05 -0400, Matthias Clasen wrote: Commit messages: Here are some recommendations that I think meet our needs: It would be nice to have hooks to enforce this in the master repo at git.gnome.org. Thoughts? Working with branches: As Kristian explained to me, there are two basic approaches to handling bug fixes in git branches. Either commit the fix on the devel branch and cherry-pick it to the stable branch, or commit the fix to the stable branch and merge the whole stable branch to the devel branch periodically. While both approaches should work, the second one has the advantage of keeping more information about the availability of the fix in the git topology. Anyway, we don't have to create a 2.16 branch today, we can take a few days to feel our way into working with git before getting serious about major feature merges. Do we want to recommend that contributors 1. submit patches to bugzilla (like we've done up until now) 2. publish a git repo with their changes Surely we would need to handle both, but it's my experience that it is much easier for maintainers to work with 2. Especially for more complicated features that include a series of patches. So maybe we want to actually recommend workflow 2 to contributors. Maybe even add some bugzilla-bling-integration, I don't know. David ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
On Tue, 2009-03-31 at 15:58 -0400, Behdad Esfahbod wrote: On 03/31/2009 03:50 PM, David Zeuthen wrote: Personally I prefer non-capital and no periods; it makes the output of 'git log |git shortlog' nicer to look at (see [1] for an example) but maybe that's just me. I think capital letters would work nice here too; trailing periods would probably look weird though. While I prefer to capitalize sentence starters, NOT capitalizing makes it easier to start a commit summary with an API symbol name or other identifiers that should not be capitalized. OTOH for the other style sometimes you want to start the summary with an abbreviation, e.g. HIG fixes. FWIW, my view is that we should capitalize summaries as most of the summaries from the importer already starts with a capital letter. David ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
On Tue, Mar 31, 2009 at 3:58 PM, Behdad Esfahbod beh...@behdad.org wrote: On 03/31/2009 03:50 PM, David Zeuthen wrote: Personally I prefer non-capital and no periods; it makes the output of 'git log |git shortlog' nicer to look at (see [1] for an example) but maybe that's just me. I think capital letters would work nice here too; trailing periods would probably look weird though. While I prefer to capitalize sentence starters, NOT capitalizing makes it easier to start a commit summary with an API symbol name or other identifiers that should not be capitalized. I don't have any strong preferences. How about the following amended version: First line (the brief description) must only be one sentence and should start with a capital letter unless it starts with a lowercase symbol or identifier. Don't use a trailing period either. Don't exceed 72 characters. Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
On Tue, 2009-03-31 at 17:03 -0400, Matthias Clasen wrote: On Tue, Mar 31, 2009 at 3:58 PM, Behdad Esfahbod beh...@behdad.org wrote: On 03/31/2009 03:50 PM, David Zeuthen wrote: Personally I prefer non-capital and no periods; it makes the output of 'git log |git shortlog' nicer to look at (see [1] for an example) but maybe that's just me. I think capital letters would work nice here too; trailing periods would probably look weird though. While I prefer to capitalize sentence starters, NOT capitalizing makes it easier to start a commit summary with an API symbol name or other identifiers that should not be capitalized. I don't have any strong preferences. How about the following amended version: First line (the brief description) must only be one sentence and should start with a capital letter unless it starts with a lowercase symbol or identifier. Don't use a trailing period either. Don't exceed 72 characters. Sounds good to me. And it would be really nice to enforce this using a git hook (repeating myself, I know). David ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
