Re: New strings in Klotski
Hello everybody, In Klotski also, but in the help files, I’ve just changed a string to fix a licensing misinformation. This program is distributed under the terms of the GNU General Public license as published by the Free Software - Foundation; either version 2 of the License, or (at your option) - any later version. A copy of this license can be found at this - link, or in the file + Foundation; either version 3 of the License, or (at your option) + any later version. A copy of this license can be found in the file COPYING included with the source code of this program. Regards, Arnaud -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
New strings in Klotski
Dear translators, I’ve just discovered that some strings in the About dialog of Klotski (gnome-klotski) were not translated (thanks to the Persian translation, where every Latin letter is a red flag). They have now been marked at translatable. There are two minor “problems” remaining (the text “GNU General Public License, version 3 or later” and the version number), but both need investigation and thinking (and maybe even coordination with other modules). Regards, Arnaud -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String freeze break request for Iagno
Hi Piotr, 2019-09-28 18:43 UTC+02:00, Piotr Drąg : > sob., 28 wrz 2019 o 18:32 Daniel Mustieles García > napisał(a): >> >> Isn't it a fix in an already marked for translation string? I thought it >> was... Sorry for the noise >> > > It is, which changes strings, i.e. breaks the string freeze. I get > confused sometimes too. :) Hey, I’m lost now! :·) The fix is already pushed, are things good for you, or should I do something more? > (For the record, I hesitated to give it my +1 because it seemed to me > like a next-release material.) Well, I agree that’s a strange situation, as that’s a fix for translations, while the English string was mostly OK (even if a bit unclear, but that only would have been for next release). Regards, Arnaud -- Arnaud Bonatti téléphone : +33(0)6 50 57 23 49 courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String freeze break request for Iagno
2019-09-28 13:13 UTC+02:00, Daniel Mustieles García : > No need to approve this since technically it's not a freeze break but here > it goes... +1 from i18n ;-) Thanks! -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String freeze break request for Iagno
Oh, right, “capturable” of course, not “capurable”. :·) Can I have a second validation from i18n here? -- Arnaud Bonatti téléphone : +33(0)6 50 57 23 49 courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [DL]String additions to 'gnome-tetravex.master'
Sorry! I forgot to branch gnome-3-34 before pushing some changes. That is now done! -- Arnaud Bonatti téléphone : +33(0)6 50 57 23 49 courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String freeze break request for Iagno
2019-09-13 15:15 UTC+02:00, Andre Klapper : > In contrast to "turnable", I have not been able to find "capurable" in > dict.leo.org or Google Translate so I have no idea what that means. From here, looks like Google Translate knows the word (?); not sure how you use it. And the Wiktionary, also. A better word for the same idea, else? > https://wiki.gnome.org/TranslationProject/DevGuidelines/Use%20comments > allows to add a comment how to [not] translate "turnable". Yeps, of course, I’ll add that to the comment if the string is not changed. :·) -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
String freeze break request for Iagno
Dear translators, The French translation (my natural language) landed in Iagno two days before the 3.34 release, and it helped me spot a quite imprecise use of words of my own, that creates some misunderstandings and a bad labeling for a function of the game in probably more than one language. I used the string “Highlight _turnable tiles” in the “Appearance” submenu of the hamburger menu, and similarly “A flag to highlight turnable tiles” as a gsettings summary for a key. This function highlights the tiles *that could be turned by a play* (in reversi, pieces have two sides, one of your color, and one of the opponent’s; and you capture by turning the piece); but it has been translated, and probably in other language than French, by “Highlight playable tiles,” making what the function does quite confusing. I’d like to clarify that in the 3.34 branch (I’ve done master first, but if you have better suggestions, I’ll change it there again also), by replacing “turnable” by “capurable”, so: “Highlight _capturable tiles” and “A flag to highlight capturable tiles,” strings that look definitively more correctly worded and more descriptive. Do you think that would be possible? Regards, Arnaud -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String & UI Freeze break request for GNOME Shell
Hey, a “small detail”: 2019-09-03 22:44 UTC+02:00, Georges Basile Stavracas Neto via gnome-i18n : > Users can use dconf-editor to rename folders, but that would make for > a terrible user experience. They cannot, there is no way to do that. Well, in fact, they can set all the things manually if they know dconf-editor as I know it, as its maintainer and main developer; but the *creation* of a folder would look impossible to most users, due to the way the settings are done (only command line allows that, more easily with `dconf` than with `gsettings`; or Software, until now at least); and there is nothing that will help them to do a *renaming*, in any way. Regards, Arnaud -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Unauthorized translation changes in dconf-editor
Hi Alexandre, 2019-03-19 11:06 UTC+01:00, Alexandre Franke : > Sadly whether we translate it or not, it will still be seen as “GNOME > software” (it lives in GNOME/ on gitlab) and his behaviour will hurt > the good reputation of our translation work. If he’s not up to the > task of maintaining that piece of software correctly then he should be > handled in an appropriate way. Honestly, I though at the opposite that this way to do things would please both translators and users. Users, because it brings to them fixes to translations in a fast way (with some errors –I’m human, and do not write all languages on Earth– but mostly with improvements), and with less regressions also, as my patches are “saving” some old strings from not being applied. Translators, because I was giving back to them my suggestions, so that they could apply it or dismiss it in the main po/ files, a good way to improve their translations faster than before, and a real quality assurance, as I’m reading translations with a completely different vision of the application and with a complete knowledge on what each string does and where it goes (in the same logic, I also tried by the way to help translators here by adding comments in the code). > We’re now beyond the honest mistake > that a beginner would make and this qualifies as hostile since he was > already warned and he created that branch to work around us. Can the > release team give him back his training wheels, please? In last year debate, what I understood was that editing po/ files in the main branches (“master” and “gnome-3-xx”) was causing problems, as translators would not always be made aware of the change; here, what I’ve done is with a completely different logic, as translators have the final decision in the end, with every change. Honestly, I didn’t imagined that translators would see something wrong with me using this new workflow, and I never thought of it as being “hostile” or “to work around [translators]”. Of course, I will stop pushing changed translations to users starting for now (and I hope I understood correctly the problem this time; are we at least ok on the words used?). Regards, Arnaud -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Unauthorized translation changes in dconf-editor
Hi Claude Paroz, hi Ask Hjorth Larsen, 2019-03-18 20:35 UTC+01:00, Claude Paroz : >> On Mon, Mar 18, 2019 at 5:02 AM, Arnaud Bonatti >> wrote: > ... >>> If a translation contains a web link to what is currently an >>> hypnotherapist website, it’s my role to remove that link before it >>> hits the stable release. Even if I didn’t had the time to join the >>> translator or its team to fix it in l10n. (Yes, it’s a true story. Not >>> a big issue, but a real life one.) > > However the example above is a typical example whete it would be crucial > that gnome-i18n is aware of the issue, because the person that committed > that is either malicious and his account should immediately be blocked, > or his account has been hacked and he should be aware of that. Of course, when I discovered that thing, I imagined various scenarii like these; but that’s clearly not the case; that’s just a domain name of a translation team that has been abandonned, and reused for something else. The link is a broken link, so it’s not a direct promotion (hopefully!), it’s just pointing to an inappropriate website. 2019-03-18 21:14 UTC+01:00, Ask Hjorth Larsen : > I agree with this - also, reporting the smaller errors to the > translation teams could mean that they are corrected elsewhere, as > they are likely repeated in the 100+ GNOME modules. I wonder if that > link is found in multiple modules? Well, if that problem is/was on my priorities of the week, that’s the reason… I think most GNOME applications have this link in their About dialog. So if it’s not a big issue in itsefl, it would be great to fix it, and everywhere. So, what’s the problem? well, dconf-editor’s Bulgarian translation po/bg.po contains: msgid "translator-credits" msgstr "" "Александър Шопов \n" "\n" "Проектът за превод на GNOME има нужда от подкрепа.\n" "Научете повече за нас на http://gnome.cult.bg\";>http://gnome.cult."; "bg\n" "Докладвайте за грешки на http://gnome.cult.bg/bugs\";>http://gnome."; "cult.bg/bugs" That text is the one displayed in the About dialog for crediting translators, but people on that list must know that. :·) The subdomain http://gnome.cult.bg is broken, hopefully, that’s why it’s clearly not malicious; but the domain http://cult.bg is… surprising. As we’re here, if someone would like to take care of contacting the correct people to fix this issue, that would be really appreciated. :·) Regards, Arnaud -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
new strings in dconf-editor and gnome-taquin
Hello dear translators! A notification: just before the string freeze, I’m changing two strings, one in dconf-editor (a clarification asked by Claude Paroz), and one in gnome-taquin (a variable type change, just me being me). Regards, Arnaud -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
“new” strings in dconf-editor
Hello dear translators! I send you this mail to inform you that you should see 4 “new” strings in dconf-editor. The story is that I’m keeping a list of capitalized and non capitalized names of the various types a simple gsettings/dconf value can have, but things were not working correctly for types names starting with “D-Bus” in English, as both capitalized and non-capitalized names were identical and so mixed by gettext (that has been reported by Marek Černocký). It took me two tries to get it right, but I think it’s correctly fixed now. Also, I’ve done a bit of code moving in gnome-2048, so if you want to have correct pointers to the code, you should refresh your potfiles. But no change of strings there. Regards, Arnaud -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [dconf-editor] String freeze break request
I pushed the patch with the two strings addition. Thanks everyone for your fast answers! 2018-08-17 19:54 UTC+02:00, Daniel Mustieles García : > 2/2 from i18n. > > Regards > > El jue., 16 ago. 2018 10:28, Claude Paroz escribió: > >> Le 16. 08. 18 à 10:05, Arnaud Bonatti via gnome-i18n a écrit : >> > Hello everybody! >> > >> > There’s a string freeze running, but I’ve spotted a mistake of my own >> > in the dconf-editor module I maintain. There’s a new information about >> > “forced range,” as the range of a numeral key can be forced or not, >> > and I’ve used an already existing translation for the “forced or not >> > forced” (“True” / “False”) info. But, this existing translation was >> > from a completely different context, and the result looks stupid in >> > some translations (Chinese where I’ve spotted the bug, but that is >> > probably not specific). >> > >> > I’d like to correct that by pushing to new strings, “Yes” and “No,” >> > that would be even better in English and that would solve the >> > contextual translations problems. Is that doable? >> >> Fine with me at this stage. i18n approval 1 of 2. >> >> Claude >> -- >> www.2xlibre.net >> ___ >> gnome-i18n mailing list >> gnome-i18n@gnome.org >> https://mail.gnome.org/mailman/listinfo/gnome-i18n -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[dconf-editor] String freeze break request
Hello everybody!
There’s a string freeze running, but I’ve spotted a mistake of my own
in the dconf-editor module I maintain. There’s a new information about
“forced range,” as the range of a numeral key can be forced or not,
and I’ve used an already existing translation for the “forced or not
forced” (“True” / “False”) info. But, this existing translation was
from a completely different context, and the result looks stupid in
some translations (Chinese where I’ve spotted the bug, but that is
probably not specific).
I’d like to correct that by pushing to new strings, “Yes” and “No,”
that would be even better in English and that would solve the
contextual translations problems. Is that doable?
Regards,
Arnaud
--
Arnaud Bonatti
courriel : arnaud.bona...@gmail.com
From f1babaa64d97e82eba145d53bd6b5167434e7aac Mon Sep 17 00:00:00 2001
From: Arnaud Bonatti
Date: Thu, 16 Aug 2018 09:00:00 +0200
Subject: [PATCH] Use Yes/No for Forced range.
---
editor/registry-info.vala | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/editor/registry-info.vala b/editor/registry-info.vala
index 3d5df44..7de6350 100644
--- a/editor/registry-info.vala
+++ b/editor/registry-info.vala
@@ -159,7 +159,7 @@ private class RegistryInfo : Grid, BrowsableView
|| type_code == "x" || type_code == "t") // signed and unsigned 64 bits
{
range_type_is_range = ((RangeType) range_type) == RangeType.RANGE;
-add_row_from_label (_("Forced range"), Key.cool_boolean_text_value (range_type_is_range));
+add_row_from_label (_("Forced range"), range_type_is_range ? _("Yes") : _("No"));
}
}
--
2.17.1
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [dconf-editor] cleaning of translations, 2nd approach
I never talked about automatic generation of content. I talked about manually fixing things in various languages, even without being part of the respective translation teams. There are tenth of strings (counting all languages) that doesn’t appear translated in the last release, but that could be fixed easily even without speaking the given languages. That’s not the end of the world, but there’s something here that can be improved; if not by fixing translation files, by fixing the code. Regards, Arnaud -- Arnaud Bonatti téléphone : +33(0)6 50 57 23 49 courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[dconf-editor] Created branch gnome-3-28
The branch 'gnome-3-28' was created pointing to: 8ad6875... Update Croatian translation ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [dconf-editor] cleaning of translations, 2nd approach
2018-03-06 20:55 UTC+01:00, Rafal Luzynski : > Back about your idea: I'm afraid it does not make much sense because > your removed strings would be restored in the next translation update. What would be restored in next translation update would be *currently used strings*, that are ok, with or without translation. What I’ve suggested to remove is *obsolete and untranslated* strings; that are making grep hard to use, because if they have been obsoleted, it’s because they were containing typographic errors or such, things that I’d like to grep to find real current typos. I’ve reported various bugs (typos, double spaces, missing spaces, bad quotation marks…) on the i10n product, found by cleaning in such a way files one time. I’m keeping my cleaning patch in my utilities, I’m just the only one who will be able to use it, instead of letting everybody look for typos. That’s inefficient, but hey, that’s humanity. ^^ Anyway, let’s not lose too much time on that. For every problem, there’s a code solution. Translations files edits would have been an easy path, but they are not necessary. Regards, Arnaud -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [dconf-editor] cleaning of translations, 2nd approach
Hi Mario, 2018-03-06 13:47 UTC+01:00, Mario Blättermann : > Never touch po files, really never. […] I don’t find a way to express how sad I am to see that it looks impossible for devs to help translators in other way than adding things to translate; and for maintainers to have a global control of the product they maintain. But OK, understood. Sorry for all the times I’ve touched a po file, that happened but won’t happen anymore. > In return, you may expect that no translator touches your source files, And I’ll revert for now any string or code change done without passing by a bug. OK. Understood. Thanks for the clarity of your answer, Cheers, Arnaud -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Unauthorized translation changes in dconf-editor
2018-03-06 12:48 UTC+01:00, Alexandre Franke : > The revert is incomplete. I’m only looking at French and I still see your > harmful change from typographic apostrophe to single quote. You’re right, I’ve forgotten something here, I’ll fix it and propose a patch in the l10n product. But my revert is manually done, I don’t know a way to check what I could have forgotten, I just know it has mostly worked. Question to the French translator: you say “harmful change from typographic apostrophe to single quote”, but the “dconf-editor” French translation uses only single quotes, sadly for me who always type with typographic apostrophe. This change I’ve done was to have the same apostrophe everywhere in the translation. Should I propose a patch that change all apostrophes to typographic apostrophe? What’s the current view of the French project? -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [dconf-editor] string freeze break (or opinions) request
2018-03-05 17:04 UTC+01:00, Piotr Drąg : >> – Proposition 1: fix the string generation using “ ” in the >> gschema file, and let translators redo the translations; >> – Proposition 2: replace the two line breaks by one space, so that >> all translations already done work, but without any line break (and >> I’d change the strings next cycle for what is wanted). > > In a perfect world, we would fix bug #793931 properly. As we live in > this world, I think proposition 2 is the best solution for 3.28, and > we can deal with the bigger problem in 3.30. The decision is yours, > though. I’ll certainly go that way if there are no other opinions on this question. >> I had also planned a 1bis proposition, where I fix the gschema file >> and all the translations in one patch, avoiding work from translators, >> but following previous discussion, that’s probably not a path I can >> follow. ;) > > The difference is that this would be a change (presumably) consulted > with and approved by the translation teams, which makes it OK. :P Something that cannot be done in one day, so a path I can’t follow. :·) Regards, Arnaud -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[dconf-editor] string freeze break (or opinions) request
Hello everybody! Reviewing translations of the “dconf-editor” module I maintain, I’ve discovered that I had a string generation problem: in the gschema file, four strings contains line breaks, but these line breaks doesn’t finish in the po files, and so the translations made by translators do not finish in the application. So sad. :·( That has been reported in the Bugzilla instance by Piotr Drąg[1] against GLib using another module as example. So. I’m not sure if I’m in a “string freeze break request” case or not (I don’t find my exact case in the Wiki[2]), but I have two proposition for fixing these bug-ly untranslated strings: – Proposition 1: fix the string generation using “ ” in the gschema file, and let translators redo the translations; – Proposition 2: replace the two line breaks by one space, so that all translations already done work, but without any line break (and I’d change the strings next cycle for what is wanted). I had also planned a 1bis proposition, where I fix the gschema file and all the translations in one patch, avoiding work from translators, but following previous discussion, that’s probably not a path I can follow. ;) Anyway, should I do something, or not, and if yes what? That’s not an important change, but for now translators are working on strings that doesn’t appear, and that lost time makes me sad. :·( Waiting for your suggestions, Arnaud [1] https://bugzilla.gnome.org/show_bug.cgi?id=793931 [2] https://wiki.gnome.org/TranslationProject/HandlingStringFreezes -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com From 6b371b87d30bb894b6038fbb443834c55b278f60 Mon Sep 17 00:00:00 2001 From: Arnaud Bonatti Date: Mon, 5 Mar 2018 09:21:47 +0100 Subject: [PATCH] Proposition 1. --- editor/ca.desrt.dconf-editor.gschema.xml | 16 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/editor/ca.desrt.dconf-editor.gschema.xml b/editor/ca.desrt.dconf-editor.gschema.xml index aeb7ccc..d3f02c5 100644 --- a/editor/ca.desrt.dconf-editor.gschema.xml +++ b/editor/ca.desrt.dconf-editor.gschema.xml @@ -234,30 +234,22 @@ 0 A D-Bus handle type, type ‘h’ - The handle type is a 32-bit signed integer value that is, by convention, used as an index into an array of file descriptors that are sent alongside a D-Bus message. - -If you are not interacting with D-Bus, then there is no reason to make use of this type. + The handle type is a 32-bit signed integer value that is, by convention, used as an index into an array of file descriptors that are sent alongside a D-Bus message. If you are not interacting with D-Bus, then there is no reason to make use of this type. '/ca/desrt/dconf_editor' A D-Bus object path, type ‘o’ - An object path is used to identify D-Bus objects at a given destination on the bus. - -If you are not interacting with D-Bus, then there is no reason to make use of this type. + An object path is used to identify D-Bus objects at a given destination on the bus. If you are not interacting with D-Bus, then there is no reason to make use of this type. ['/ca/desrt/dconf_editor/menus/appmenu', '/ca/desrt/dconf_editor/window/1'] A D-Bus object path array, type ‘ao’ - An object path array could contain any number of object paths (including none: “[]”). - -If you are not interacting with D-Bus, then there is no reason to make use of this type. + An object path array could contain any number of object paths (including none: “[]”). If you are not interacting with D-Bus, then there is no reason to make use of this type. 'ii' A D-Bus signature, type ‘g’ - A D-Bus signature is a string used as type signature for a D-Bus method or message. - -If you are not interacting with D-Bus, then there is no reason to make use of this type. + A D-Bus signature is a string used as type signature for a D-Bus method or message. If you are not interacting with D-Bus, then there is no reason to make use of this type. 3.1415926535897933 -- 2.14.3 From d3c7ca4d70af2409ff8bfa52d2b65d53187d5c6a Mon Sep 17 00:00:00 2001 From: Arnaud Bonatti Date: Mon, 5 Mar 2018 09:22:28 +0100 Subject: [PATCH] Proposition 2. --- editor/ca.desrt.dconf-editor.gschema.xml | 16 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/editor/ca.desrt.dconf-editor.gschema.xml b/editor/ca.desrt.dconf-editor.gschema.xml index aeb7ccc..f6ec818 100644 --- a/editor/ca.desrt.dconf-editor.gschema.xml +++ b/editor/ca.desrt.dconf-editor.gschema.xml @@ -234,30 +234,22 @@ 0 A D-Bus handle type, type ‘h’ - The handle type is a 32-bit signed integer value that is, by convention, used as an index into an array of file descriptors that are sent alongside a D-Bus message. - -If you are not interacting with D-Bus, then there is no reason to
Re: Unauthorized translation changes in dconf-editor
2018-03-04 19:16 UTC+01:00, Piotr Drąg : > If it’s doable, then do it. Preferably right now. Done, and sorry again for the inconvenience! -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Unauthorized translation changes in dconf-editor
2018-03-04 18:02 UTC+01:00, Piotr Drąg : > You’re welcome to post patches at > <https://bugzilla.gnome.org/page.cgi?id=browse.html&product=l10n> next > time you feel like “improving”. I’ll remember that. > It would be best if you could revert all these commits. Well… that’s doable of course. But with the current state of things, it’s easy to use the `grep` tool to find some translations bugs like quoting mark errors in translations (\n instead of „/“/”/«/»/etc., or the opposite), where it was completely impossible with the previous noise, and the same with the spacing/non-spacing/other before “bit” (and other use cases). Of course, if some specific projects prefer, I’ll revert my change on their po file, but I really don’t think it’s a good idea to remove as a whole. Not even counting all the lost fixes. -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Unauthorized translation changes in dconf-editor
Hi everybody, sorry for the delayed reply. I don’t check these lists daily, and my filters has also hidden the direct mail, sorry Piotr Drąg. :·( 2018-03-01 18:18 UTC+01:00, Piotr Drąg : > A few days ago Arnaud Bonatti, the dconf-editor maintainer, started > committing changes to translations: > > https://git.gnome.org/browse/dconf-editor/log/po?qt=author&q=Arnaud+Bonatti Yes. I’m sorry. I’m a perfectionist, and directly working on things helps me seen how the “dconf-editor product” finishes in people hands, for improving it. In all my po files edits, I’ve spotted tenths of typos in various languages, one bug in the generation of eight strings (translated by translators, but not applied to the application; I’m currently working on a fix for before the last unstable release), and one case where I should improve code for helping i18n. Hope that hasn’t caused too much “harm” for teams, but that has been really helpful from a releaser/maintainer point of view. I’ve notably realized how many strings are translated and how useful/not-so-useful ones are mixed, and will probably ask for a split of the “demo” string in a following cycle, so translators of small teams could concentrate on the application general UI. And globally, I’m more aware now of some problems of my code, and that’ll help in the future. 2018-03-01 21:10 UTC+01:00, Michael Catanzaro : > Normally, the translators like to update their po files themselves. > Just like you probably don't want translators modifying your code. ;) I > know you're just trying to reduce fuzziness of the strings, but I would > leave these files alone from now on, OK? Well, if some translators want to improved my code in revenge, I’d honestly thank them to do so. ^^ But I understood, that’s not something I’ll redo, I just needed to have a view of what was happening between code and users, and that has been enlightening. I’ve finished, apart for the big bug I’m working on, but that’s for a following email. ^^ Regards, Arnaud -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[dconf-editor] new strings
Hi! I think I’ve more or less finished with changes in dconf-editor, time for it to enter (quite late) in beta stage. The cycle has globally been quite busy regarding translations, including new error messages and new demo/test keys, but there are some quite recent changes that I have to notify: [1fd3a64e] two new strings, part of the UI, where “%s” will be replaced by a path: Folder “%s” is now empty. Key “%s” has been deleted. [06efec5e] three/four new strings (one duplicate), in the demo/test keys: Conflicting key with no range that should give an error This key is a test for multiple schemas in the same path with conflicting keys. It shouldn’t be editable as a key mapped to the same path has a different range. Conflicting key with range 0~5 that should give an error [e8f8a097] grammar error correction (bug 793202): This key properties have changed. Do you want to reload the view? became: This key’s properties have changed. Do you want to reload the view? There has been also some recent files splits, but they shouldn’t impact the translations. Thank you everybody for your hard work! Let’s make 3.28 a great release. :) -- Arnaud Bonatti courriel : arnaud.bona...@gmail.com ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[dconf-editor] Created branch gnome-3-24
The branch 'gnome-3-24' was created pointing to: be5aa08... Update Polish translation ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[dconf-editor] Created branch gnome-3-26
The branch 'gnome-3-26' was created pointing to: a2cf8f7... Prepare 3.26.1. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-2048] Created branch gnome-3-26
The branch 'gnome-3-26' was created pointing to: 0a4020f... Prepare 3.26.1. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[iagno] Created branch gnome-3-26
The branch 'gnome-3-26' was created pointing to: c951719... Prepare 3.26.1. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-taquin] Created branch gnome-3-26
The branch 'gnome-3-26' was created pointing to: 00bbeb6... Prepare 3.26.1. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[dconf-editor] Created branch gnome-3-22
The branch 'gnome-3-22' was created pointing to: b0488a5... Don't hardcode a color. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-taquin] Created branch gnome-3-20
The branch 'gnome-3-20' was created pointing to: 8f6aa6a... Prepare 3.20.1. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-2048] Created branch gnome-3-20
The branch 'gnome-3-20' was created pointing to: 5a1a073... Prepare 3.20.1. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[iagno] Created branch gnome-3-20
The branch 'gnome-3-20' was created pointing to: 86f1f0b... Prepare 3.20.1. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[dconf-editor] Created branch gnome-3-20
The branch 'gnome-3-20' was created pointing to: c586509... Correctly quit with app-menu action. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-klotski] Created branch gnome-3-18
The branch 'gnome-3-18' was created pointing to: 101667d... Prepare 3.18.1 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-2048] Created branch gnome-3-18
The branch 'gnome-3-18' was created pointing to: f9ec8f2... Prepare 3.18.0 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-taquin] Created branch gnome-3-18
The branch 'gnome-3-18' was created pointing to: 33fdbea... Prepare 3.18.0 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[iagno] Created branch gnome-3-18
The branch 'gnome-3-18' was created pointing to: a1b7f1f... Prepare 3.18.0 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[dconf-editor] Created branch gnome-3-18
The branch 'gnome-3-18' was created pointing to: bf27e82... Prepare 3.18.0 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[dconf-editor] Created branch gnome-3-16
The branch 'gnome-3-16' was created pointing to: 713b0d5... Fix distcheck (Autotools bug). ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gnome-taquin] Created branch gnome-3-16
The branch 'gnome-3-16' was created pointing to: 89c0297... Updated Basque language ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[iagno] Created branch gnome-3-16
The branch 'gnome-3-16' was created pointing to: dbac4a2... Updated Basque language ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
