[DL]String additions to 'glib-networking.master'
This is an automatic notification from status generation scripts on: https://l10n.gnome.org. There have been following string additions to module 'glib-networking.master': + "Controls whether session should reuse a previous session or if it should be stored. In tests, this variable is false by default." + "Indicates whether a session has been reused" + "Session Reuse Enabled" + "Session Reused" Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. https://gitlab.gnome.org/GNOME/glib-networking/commits/master ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[DL]String additions to 'glib-networking.master'
This is an automatic notification from status generation scripts on: https://l10n.gnome.org. There have been following string additions to module 'glib-networking.master': + "Failed to import PKCS #12: %s" Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. https://gitlab.gnome.org/GNOME/glib-networking/commits/master ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[DL]String additions to 'glib-networking.master'
This is an automatic notification from status generation scripts on: https://l10n.gnome.org. There have been following string additions to module 'glib-networking.master': + "Empty channel binding data indicates a bug in the TLS library implementation" + "The request is invalid." Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. https://gitlab.gnome.org/GNOME/glib-networking/commits/master ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[DL]String additions to 'glib-networking.master'
This is an automatic notification from status generation scripts on: https://l10n.gnome.org. There have been following string additions to module 'glib-networking.master': + "Could not get CA certificate store" + "Could not get root certificate store" Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. https://gitlab.gnome.org/GNOME/glib-networking/commits/master ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[DL]String additions to 'glib-networking.master'
This is an automatic notification from status generation scripts on: https://l10n.gnome.org. There have been following string additions to module 'glib-networking.master': + "Channel binding data for tls-unique is not yet available" + "Channel binding data tls-unique is not available" + "Channel binding type tls-unique is not implemented in the TLS library" + "Current X.509 certificate uses unknown or unsupported signature algorithm" + "Failed to generate X.509 certificate digest" + "Handshake is not finished, no channel binding information yet" + "Requested channel binding type is not implemented" + "TLS Connection does not support TLS-Exporter feature" + "Unable to obtain certificate signature algorithm" Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. https://gitlab.gnome.org/GNOME/glib-networking/commits/master ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[DL]String additions to 'glib-networking.master'
This is an automatic notification from status generation scripts on: https://l10n.gnome.org. There have been following string additions to module 'glib-networking.master': + "Channel binding data for tls-unique is not yet available" + "Channel binding data tls-unique is not available" + "Channel binding type tls-unique is not implemented in the TLS library" + "Current X.509 certificate uses unknown or unsupported signature algorithm" + "Failed to generate X.509 certificate digest" + "Handshake is not finished, no channel binding information yet" + "Requested channel binding type is not implemented" + "TLS Connection does not support TLS-Exporter feature" + "Unable to obtain certificate signature algoritm" Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. https://gitlab.gnome.org/GNOME/glib-networking/commits/master ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[DL]String additions to 'glib-networking.master'
This is an automatic notification from status generation scripts on: https://l10n.gnome.org. There have been following string additions to module 'glib-networking.master': + "%s: The connection is broken" + "Could not set MAX protocol to %ld: %s" + "Failed to populate trust list from %s: %s" + "Secure renegotiation is disabled" Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. https://gitlab.gnome.org/GNOME/glib-networking/commits/master ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[DL]String additions to 'glib-networking.master'
This is an automatic notification from status generation scripts on: https://l10n.gnome.org. There have been following string additions to module 'glib-networking.master': + "Could not import PKCS #11 certificate URI: %s" Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. https://gitlab.gnome.org/GNOME/glib-networking/commits/master ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Minor string changes in libgdata and GLib
Hi all, A couple of small string changes in libgdata and GLib before the string freeze on 2019-08-19. Both changes are to strings which the user will not commonly see (a string in an error message in libgdata, and a string in a developer tool error message in GLib). Both changes are to convert a British English spelling into a US English one, so shouldn’t affect any translations except en_* ones. https://gitlab.gnome.org/GNOME/libgdata/merge_requests/15 https://gitlab.gnome.org/GNOME/glib/merge_requests/1038 Philip ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[DL] String additions to 'glib-networking.master'
This is an automatic notification from status generation scripts on: https://l10n.gnome.org. There have been following string additions to module 'glib-networking.master': + "Could not create CA store" + "Failed to load file path: %s" Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. https://gitlab.gnome.org/GNOME/glib-networking/commits/master ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[DL] String additions to 'glib-networking.master'
This is an automatic notification from status generation scripts on: https://l10n.gnome.org. There have been following string additions to module 'glib-networking.master': + "Cannot perform blocking operation during TLS handshake" Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. https://gitlab.gnome.org/GNOME/glib-networking/commits/master ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Updated month name translations needed in GLib
Sgrìobh Rafal Luzynski na leanas 26/03/2018 aig 21:39: > 26.03.2018 13:43 Fòram na Gàidhlig wrote: >> >> >>>> Reminder for *every* translation team: you should update strings from >>>> glib/gdatetime.c in GLib to avoid a chance of English dates in the >>>> next GNOME release. Languages which won’t get an update soon will get >>>> a commit from https://gitlab.gnome.org/GNOME/glib/commits/wip/piotrdr >>>> ag/missing-months >>>> merged. >>> >>> I have merged that branch to GLib master, so it will be in the 2.56.0 >>> release. There is still time for translation teams to update the >>> strings there before the release, if you spot any problems with them. >>> >>> (Please CC me in any replies as I am not subscribed to gnome-i18n.) >> >> I tried to look at Piotr's commit to try to find our what I need to do, >> but the link is dead now. > > Piotr already provided the updated commit link but for the record and > for other languages this link may be helpful, at least now, as we are > shortly after these changes: > > https://gitlab.gnome.org/GNOME/glib/commits/master/po > >> Any chance to have an idiot's guide on which file to edit, and which one >> will be the stand-alone form? > > You should edit (or actually: review if it is edited correctly) your > translation for glib project in Damned Lies. As Piotr said, the stand-alone > form is the one with the old "full month name" and "abbreviated month name" > context. I find it ambiguous and wanted to introduce "full month name > standalone" and "abbreviated month name standalone" but the glib > maintainer said that this drops existing translations and does not > provide any additional value. > > Also I think that the translators comment before "January"/"Jan" > is a sufficient "idiot's guide" (sorry, that's not my opinion.) :-) > If not then please explain how to fix it. > > While at this, the translators comments mention that you should refer > to the latest glibc and some command line utilities and see how they > handle the month names. But this is not true for Scottish Gaelic > (as well as for some other languages). The reason is that I did not > have any feedback from you recently (but of course I really appreciate > your feedback I received about a year ago) and I did not want to > introduce changes to the locales without the final ack from the > actual translation teams; also I did not have time to ping each > translation team individually. As a result there are some languages > where the nominative/genitive month names are (probably) needed but > they are not yet supported. I guess what confused me is the talk of direct git commits - so I thought that I had to do soething special here. Thanks to the link to the commit, I have now found them in the current development branch on Damned Lies. The comments are indeed sufficient :) ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Updated month name translations needed in GLib
26.03.2018 13:43 Fòram na Gàidhlig wrote: > > > >> Reminder for *every* translation team: you should update strings from > >> glib/gdatetime.c in GLib to avoid a chance of English dates in the > >> next GNOME release. Languages which won’t get an update soon will get > >> a commit from https://gitlab.gnome.org/GNOME/glib/commits/wip/piotrdr > >> ag/missing-months > >> merged. > > > > I have merged that branch to GLib master, so it will be in the 2.56.0 > > release. There is still time for translation teams to update the > > strings there before the release, if you spot any problems with them. > > > > (Please CC me in any replies as I am not subscribed to gnome-i18n.) > > I tried to look at Piotr's commit to try to find our what I need to do, > but the link is dead now. Piotr already provided the updated commit link but for the record and for other languages this link may be helpful, at least now, as we are shortly after these changes: https://gitlab.gnome.org/GNOME/glib/commits/master/po > Any chance to have an idiot's guide on which file to edit, and which one > will be the stand-alone form? You should edit (or actually: review if it is edited correctly) your translation for glib project in Damned Lies. As Piotr said, the stand-alone form is the one with the old "full month name" and "abbreviated month name" context. I find it ambiguous and wanted to introduce "full month name standalone" and "abbreviated month name standalone" but the glib maintainer said that this drops existing translations and does not provide any additional value. Also I think that the translators comment before "January"/"Jan" is a sufficient "idiot's guide" (sorry, that's not my opinion.) :-) If not then please explain how to fix it. While at this, the translators comments mention that you should refer to the latest glibc and some command line utilities and see how they handle the month names. But this is not true for Scottish Gaelic (as well as for some other languages). The reason is that I did not have any feedback from you recently (but of course I really appreciate your feedback I received about a year ago) and I did not want to introduce changes to the locales without the final ack from the actual translation teams; also I did not have time to ping each translation team individually. As a result there are some languages where the nominative/genitive month names are (probably) needed but they are not yet supported. Regards, Rafal ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Updated month name translations needed in GLib
2018-03-26 13:43 GMT+02:00 Fòram na Gàidhlig : >>> Reminder for *every* translation team: you should update strings from >>> glib/gdatetime.c in GLib to avoid a chance of English dates in the >>> next GNOME release. Languages which won’t get an update soon will get >>> a commit from https://gitlab.gnome.org/GNOME/glib/commits/wip/piotrdr >>> ag/missing-months >>> merged. >> >> I have merged that branch to GLib master, so it will be in the 2.56.0 >> release. There is still time for translation teams to update the >> strings there before the release, if you spot any problems with them. >> >> (Please CC me in any replies as I am not subscribed to gnome-i18n.) > > I tried to look at Piotr's commit to try to find our what I need to do, > but the link is dead now. > > Any chance to have an idiot's guide on which file to edit, and which one > will be the stand-alone form? > Here are the added translations: https://gitlab.gnome.org/GNOME/glib/commit/9aee2f4e04cf58feefd88be40a77a3a4a9f86684 These are used for formatting dates. Existing “full month name” in the same file are used for months without days. Best regards, -- Piotr Drąg https://piotrdrag.fedorapeople.org ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Updated month name translations needed in GLib
>> Reminder for *every* translation team: you should update strings from >> glib/gdatetime.c in GLib to avoid a chance of English dates in the >> next GNOME release. Languages which won’t get an update soon will get >> a commit from https://gitlab.gnome.org/GNOME/glib/commits/wip/piotrdr >> ag/missing-months >> merged. > > I have merged that branch to GLib master, so it will be in the 2.56.0 > release. There is still time for translation teams to update the > strings there before the release, if you spot any problems with them. > > (Please CC me in any replies as I am not subscribed to gnome-i18n.) I tried to look at Piotr's commit to try to find our what I need to do, but the link is dead now. Any chance to have an idiot's guide on which file to edit, and which one will be the stand-alone form? signature.asc Description: OpenPGP digital signature ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Updated month name translations needed in GLib
On Sat, 2018-03-03 at 22:49 +0100, Piotr Drąg wrote: > 2018-02-21 12:49 GMT+01:00 Philip Withnall : > > Hi all, > > > > (I’m not subscribed to the list, so please CC me in replies.) > > > > As discussed previously[1], nominative/genitive month name support > > has > > come to GLib. We’ve got a few unit tests which depend on > > translations > > existing for the new month name strings[2] which are currently > > broken > > due to the new strings being missing in the following locales: > > • fr_FR > > • el_GR > > • hr_HR > > • lt_LT > > • ru_RU > > > > There’s also this bug[3] which requires the same updates in ja_JP. > > > > Could the translation teams please prioritise updating the month > > name > > strings in GLib? Both for the sake of making the tests pass, and > > for > > making sure users in your locale get correctly-translated month > > names. > > In locales with no nominative/genitive difference, you still need > > to > > update the translations to avoid the C-locale string being used in > > the > > new context. > > > > For many languages, this will be a case of copying the existing > > strings > > from one context to the other, unchanged. Those languages which > > have a > > difference between nominative and genitive forms will have to be a > > bit > > more careful. Typically, the strings should be the same as the > > output > > of `locale mon` on a system running the latest glibc release. > > > > If anybody has any questions about the translations, let me or > > Rafal > > know. > > > > Reminder for *every* translation team: you should update strings from > glib/gdatetime.c in GLib to avoid a chance of English dates in the > next GNOME release. Languages which won’t get an update soon will get > a commit from https://gitlab.gnome.org/GNOME/glib/commits/wip/piotrdr > ag/missing-months > merged. I have merged that branch to GLib master, so it will be in the 2.56.0 release. There is still time for translation teams to update the strings there before the release, if you spot any problems with them. (Please CC me in any replies as I am not subscribed to gnome-i18n.) Thanks, Philip signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Updated month name translations needed in GLib
2018-02-21 12:49 GMT+01:00 Philip Withnall : > Hi all, > > (I’m not subscribed to the list, so please CC me in replies.) > > As discussed previously[1], nominative/genitive month name support has > come to GLib. We’ve got a few unit tests which depend on translations > existing for the new month name strings[2] which are currently broken > due to the new strings being missing in the following locales: > • fr_FR > • el_GR > • hr_HR > • lt_LT > • ru_RU > > There’s also this bug[3] which requires the same updates in ja_JP. > > Could the translation teams please prioritise updating the month name > strings in GLib? Both for the sake of making the tests pass, and for > making sure users in your locale get correctly-translated month names. > In locales with no nominative/genitive difference, you still need to > update the translations to avoid the C-locale string being used in the > new context. > > For many languages, this will be a case of copying the existing strings > from one context to the other, unchanged. Those languages which have a > difference between nominative and genitive forms will have to be a bit > more careful. Typically, the strings should be the same as the output > of `locale mon` on a system running the latest glibc release. > > If anybody has any questions about the translations, let me or Rafal > know. > Reminder for *every* translation team: you should update strings from glib/gdatetime.c in GLib to avoid a chance of English dates in the next GNOME release. Languages which won’t get an update soon will get a commit from https://gitlab.gnome.org/GNOME/glib/commits/wip/piotrdrag/missing-months merged. Thank you for your hard work, -- Piotr Drąg https://piotrdrag.fedorapeople.org ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Updated month name translations needed in GLib
Le 21. 02. 18 à 12:49, Philip Withnall a écrit : (...) We’ve got a few unit tests which depend on translations existing for the new month name strings[2] which are currently broken due to the new strings being missing in the following locales: • fr_FR fr_FR is done. Cheers, Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Updated month name translations needed in GLib
21.02.2018 12:49 Philip Withnall wrote: > > Hi all, > > (I’m not subscribed to the list, so please CC me in replies.) > > As discussed previously[1], nominative/genitive month name support has > come to GLib. We’ve got a few unit tests which depend on translations > existing for the new month name strings[2] which are currently broken > due to the new strings being missing in the following locales: > • fr_FR > • el_GR > • hr_HR > • lt_LT > • ru_RU > > There’s also this bug[3] which requires the same updates in ja_JP. To be honest, all translations need an update. There is nothing special with the locales you mentioned above except that they have been used in the tests. Have we got any superpower to update all translations adding the missing (genitive) month names as the copy of the existing (nominative) month names? I am aware that some teams have been inactive and the translations have not been updated for years. In 90% of the cases copy&paste the existing month names is the correct solution. > Could the translation teams please prioritise updating the month name > strings in GLib? Both for the sake of making the tests pass, and for > making sure users in your locale get correctly-translated month names. > In locales with no nominative/genitive difference, you still need to > update the translations to avoid the C-locale string being used in the > new context. > > For many languages, this will be a case of copying the existing strings > from one context to the other, unchanged. Those languages which have a > difference between nominative and genitive forms will have to be a bit > more careful. Typically, the strings should be the same as the output > of `locale mon` on a system running the latest glibc release. > > If anybody has any questions about the translations, let me or Rafal > know. > > Thanks! > Philip That's perfectly correct. Thank you Philip for coordinating this task so accurately. Regards, Rafal ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Updated month name translations needed in GLib
Hi all, (I’m not subscribed to the list, so please CC me in replies.) As discussed previously[1], nominative/genitive month name support has come to GLib. We’ve got a few unit tests which depend on translations existing for the new month name strings[2] which are currently broken due to the new strings being missing in the following locales: • fr_FR • el_GR • hr_HR • lt_LT • ru_RU There’s also this bug[3] which requires the same updates in ja_JP. Could the translation teams please prioritise updating the month name strings in GLib? Both for the sake of making the tests pass, and for making sure users in your locale get correctly-translated month names. In locales with no nominative/genitive difference, you still need to update the translations to avoid the C-locale string being used in the new context. For many languages, this will be a case of copying the existing strings from one context to the other, unchanged. Those languages which have a difference between nominative and genitive forms will have to be a bit more careful. Typically, the strings should be the same as the output of `locale mon` on a system running the latest glibc release. If anybody has any questions about the translations, let me or Rafal know. Thanks! Philip [1]: https://mail.gnome.org/archives/gnome-i18n/2018-February/msg00014. html [2]: https://bugzilla.gnome.org/show_bug.cgi?id=793645 [3]: https://bugzilla.gnome.org/show_bug.cgi?id=793578 signature.asc Description: This is a digitally signed message part ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [glib][GDateTime] API and string freeze break request
12.02.2018 22:38 mcatanz...@gnome.org wrote: > > > On Mon, Feb 12, 2018 at 1:54 PM, Rafal Luzynski > wrote: > > Thank you. So here I have the feedback from the i18n team, as > > Alexandre said I don't need an approval yet. What about any feedback > > from the documentation and release team? Maybe I don't need an > > approval as well? > > You do need two approvals from release-team. This is your first, > [...] Again, thank you Michael for your approval and review. Who will give me a second approval and a second review? I think this change is necessary because as glibc has introduced nominative/genitive cases (in those languages which distinguish them) glib now displays a genitive case everywhere. Which is usually correct but sometimes not, for those exceptional cases we need "%OB". Links: https://bugzilla.gnome.org/show_bug.cgi?id=749206 https://gitlab.gnome.org/GNOME/libdazzle/issues/8 https://gitlab.gnome.org/GNOME/gnome-todo/issues/147 Regards, Rafal ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [glib][GDateTime] API and string freeze break request
12.02.2018 22:38 mcatanz...@gnome.org wrote: > > > On Mon, Feb 12, 2018 at 1:54 PM, Rafal Luzynski > wrote: > > Thank you. So here I have the feedback from the i18n team, as > > Alexandre said I don't need an approval yet. What about any feedback > > from the documentation and release team? Maybe I don't need an > > approval as well? > > You do need two approvals from release-team. This is your first, Thank you. > because I assume this change is unlikely to break application unless > they use the new API. Define "break". Sure, under no condition it causes any crash, sigsegv, etc. Only makes some applications (dates, calendars) look ugly if this patch is not applied or if it is applied incorrectly. As much as possible I'm trying to address all affected places and I hope to manage this task. Although I'll appreciate any help. Regards, Rafal ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [glib][GDateTime] API and string freeze break request
On Mon, Feb 12, 2018 at 1:54 PM, Rafal Luzynski wrote: Thank you. So here I have the feedback from the i18n team, as Alexandre said I don't need an approval yet. What about any feedback from the documentation and release team? Maybe I don't need an approval as well? You do need two approvals from release-team. This is your first, because I assume this change is unlikely to break application unless they use the new API. Michael ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [glib][GDateTime] API and string freeze break request
12.02.2018 18:11 Piotr Drąg napisał(a): > > > 2018-02-08 1:22 GMT+01:00 Rafal Luzynski : > > * String changes: new forms of month names will have to be added. > > Bad news: for all (really all) languages. Good news: in 90% of languages > > it will be just a copy of existing month names; also these month names > > will be actually used only on those systems which do not yet provide > > them (the latest glibc 2.27 supports all, BSD partially). Does anybody > > have a superpower to insert the month names if the translators are > > inactive? > > > > I’m, obviously, very much in favor of this change, as should be other > translators of affected languages. Thank you. So here I have the feedback from the i18n team, as Alexandre said I don't need an approval yet. What about any feedback from the documentation and release team? Maybe I don't need an approval as well? > I suppose we could review and push a patch that adds translations for > month names in less active languages, especially since it should be a > relatively simple import of glibc/CLDR data. This would be perfect, if needed. Regards, Rafal ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [glib][GDateTime] API and string freeze break request
2018-02-08 1:22 GMT+01:00 Rafal Luzynski : > * String changes: new forms of month names will have to be added. > Bad news: for all (really all) languages. Good news: in 90% of languages > it will be just a copy of existing month names; also these month names > will be actually used only on those systems which do not yet provide > them (the latest glibc 2.27 supports all, BSD partially). Does anybody > have a superpower to insert the month names if the translators are > inactive? > I’m, obviously, very much in favor of this change, as should be other translators of affected languages. I suppose we could review and push a patch that adds translations for month names in less active languages, especially since it should be a relatively simple import of glibc/CLDR data. Best regards, -- Piotr Drąg https://piotrdrag.fedorapeople.org ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [glib][GDateTime] API and string freeze break request
8.02.2018 11:08 Alexandre Franke wrote: > > [...] We would appreciate if you could give us an idea of the > number of new strings. 24 strings, which is the number of months in year in Gregorian calendar multiplied by 2 (full names and abbreviated names) while in most of the languages they will be just a copy of existing month names. Although as the patch is not yet accepted and can be discussed I'd prefer an option where due to the context change 24 existing strings are split into 48 strings to avoid the confusion why the translators having provided "month names" must again provide "month names as used in dates". > > This freeze break request will be followed by more freeze break > > requests (string only): > > Depending on when that happens, you may still not be in string freeze yet. I'm currently reviewing my old patches and indeed it seems that some of them do not need to wait for glib2 patches and can be accepted as soon as the maintainers agree. Regards, Rafal ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [glib][GDateTime] API and string freeze break request
Hi, On Thu, Feb 8, 2018 at 1:22 AM, Rafal Luzynski wrote: > * String changes: new forms of month names will have to be added. > Bad news: for all (really all) languages. Good news: in 90% of languages > it will be just a copy of existing month names; also these month names > will be actually used only on those systems which do not yet provide > them (the latest glibc 2.27 supports all, BSD partially). Does anybody > have a superpower to insert the month names if the translators are > inactive? Thanks for the heads up. We are currently in string change announcement period and the freeze has not started yet, so you don’t need approval. We would appreciate if you could give us an idea of the number of new strings. > This freeze break request will be followed by more freeze break > requests (string only): Depending on when that happens, you may still not be in string freeze yet. -- Alexandre Franke GNOME Hacker & Foundation Director ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[glib][GDateTime] API and string freeze break request
I'd like to ask for the freeze break approval in order to add a missing functionality as described in bug 749206. [1] Also, as the patches are not yet accepted and committed, I'd like to ask for more reviews and to commit. Planned changes === * API: g_date_time_format() function will support the new format specifiers: %OB, %Ob, and %Oh. Also the meaning of %B, %b, %h will be slightly changed (actually: will be specified more precisely). * String changes: new forms of month names will have to be added. Bad news: for all (really all) languages. Good news: in 90% of languages it will be just a copy of existing month names; also these month names will be actually used only on those systems which do not yet provide them (the latest glibc 2.27 supports all, BSD partially). Does anybody have a superpower to insert the month names if the translators are inactive? Why this change is important and why it is so late == This change follows the latest change in glibc strftime() function. [2] [3] The aim of the change is to support two grammatical cases of month names, as required by some eastern European languages. This is included in the most recent glibc 2.27 released on February 1 (1 week ago) while the change has been finally accepted and applied upstream only on January 22 (2.5 weeks ago). As a result, g_date_strftime() (being just a wrapper for stftime() ) supports the new format specifiers already if its underlying platform's C library is glibc 2.27. g_date_time_format() currently does not support %OB, %Ob, and %Oh format specifiers while it has already switched to displaying %B, %b, %h in a genitive case (in selected languages only) which is correct in most cases but incorrect in few, and that's why we need this change. The patch falls back to the underlying platform if it supports all forms of the month names correctly (glibc 2.27 only) and provides a correct implementation for the platforms which support the feature incompletely (BSD) or incorrectly (older glibc). There is also another patch which provides the same functionality for MS Windows. If these patches are not applied GNOME will remain in the middle of transition. Followups = This freeze break request will be followed by more freeze break requests (string only): * in gnome-shell (calendar widget), [4] [5] * in gnome-calendar, [6] * in shotwell (not yet reported anywhere) Thanks in advance, Rafal [1] https://bugzilla.gnome.org/show_bug.cgi?id=749206 [2] https://sourceware.org/bugzilla/show_bug.cgi?id=10871 [3] https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD [4] https://bugzilla.gnome.org/show_bug.cgi?id=781329 [5] https://bugzilla.gnome.org/show_bug.cgi?id=780957 [6] https://gitlab.gnome.org/GNOME/gnome-calendar/issues/125 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[geocode-glib] Created branch gnome-3-24
The branch 'gnome-3-24' was created. Summary of new commits: aa513ab... Release 3.24.0 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[DL] String additions to 'glib-networking.master'
This is an automatic notification from status generation scripts on: https://l10n.gnome.org. There have been following string additions to module 'glib-networking.master': + "Peer sent fatal TLS alert: %s" Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. https://git.gnome.org/browse/glib-networking/log/?h=master ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[geocode-glib] Created branch gnome-3-20
The branch 'gnome-3-20' was created pointing to: 8bbf72c... Release 3.20.1 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[geocode-glib] Created branch gnome-3-18
The branch 'gnome-3-18' was created pointing to: a3e183e... Release 3.18.0 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[geocode-glib] Created branch gnome-3-16
The branch 'gnome-3-16' was created pointing to: 8877b11... reverse: Check for NULL from json_reader_list_members() ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
GLib is branched
karaj, I just released GLib 2.43.92 and branched. 'glib-2-44' is what will become 2.44.0 and 'master' is what will become 2.46. Cheers ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[geocode-glib] Created branch gnome-3-14
The branch 'gnome-3-14' was created pointing to: b571940... location: Fix error handling in uri parsing ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[geocode-glib] Created branch gnome-3-12
The branch 'gnome-3-12' was created pointing to: 9872e31... Release 3.12.0 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
GLib 2.38 branched
hi all, I just branched off GLib 2.38 as glib-2-38. 'master' is now fully unfrozen and will become 2.40. Cheers ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[geocode-glib] Created branch gnome-3-10
The branch 'gnome-3-10' was created pointing to: fb5269a... Release 3.10.0 ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: problem git push to glib-networking
On Fri, Mar 29, 2013 at 4:04 PM, Andre Klapper wrote: > On Fri, 2013-03-29 at 13:09 +0700, Andika Triwidada wrote: >> > Can somebody tell me what's wrong? >> > Why insufficient permission? > > See the previous post on this mailing list. Ah. Thank you. I missed that post. > > andre > -- > Andre Klapper | ak...@gmx.net > http://blogs.gnome.org/aklapper/ > ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: problem git push to glib-networking
On Fri, 2013-03-29 at 13:09 +0700, Andika Triwidada wrote: > > Can somebody tell me what's wrong? > > Why insufficient permission? See the previous post on this mailing list. andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: problem git push to glib-networking
also happened to glib $ git push Counting objects: 7, done. Delta compression using up to 2 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 6.69 KiB, done. Total 4 (delta 3), reused 0 (delta 0) error: insufficient permission for adding an object to repository database ./objects fatal: failed to write object error: unpack failed: unpack-objects abnormal exit To ssh://git.gnome.org/git/glib ! [remote rejected] HEAD -> glib-2-36 (n/a (unpacker error)) error: failed to push some refs to 'ssh://git.gnome.org/git/glib' On Fri, Mar 29, 2013 at 1:00 PM, Andika Triwidada wrote: > Tried to push to glib-networking and got this error: > > $ git push --verbose > Pushing to ssh://git.gnome.org/git/glib-networking > Counting objects: 7, done. > Delta compression using up to 2 threads. > Compressing objects: 100% (4/4), done. > Writing objects: 100% (4/4), 641 bytes, done. > Total 4 (delta 3), reused 0 (delta 0) > error: insufficient permission for adding an object to repository > database ./objects > > fatal: failed to write object > error: unpack failed: unpack-objects abnormal exit > To ssh://git.gnome.org/git/glib-networking > ! [remote rejected] master -> master (n/a (unpacker error)) > error: failed to push some refs to 'ssh://git.gnome.org/git/glib-networking' > > Can somebody tell me what's wrong? > Why insufficient permission? > > TIA > -- > andika ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
problem git push to glib-networking
Tried to push to glib-networking and got this error: $ git push --verbose Pushing to ssh://git.gnome.org/git/glib-networking Counting objects: 7, done. Delta compression using up to 2 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 641 bytes, done. Total 4 (delta 3), reused 0 (delta 0) error: insufficient permission for adding an object to repository database ./objects fatal: failed to write object error: unpack failed: unpack-objects abnormal exit To ssh://git.gnome.org/git/glib-networking ! [remote rejected] master -> master (n/a (unpacker error)) error: failed to push some refs to 'ssh://git.gnome.org/git/glib-networking' Can somebody tell me what's wrong? Why insufficient permission? TIA -- andika ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions to 'glib-networking.master'
This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'glib-networking.master': + "TLS connection peer did not send a certificate" Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. http://git.gnome.org/browse/glib-networking/log/?h=master ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'glib-networking.master'
El dj 19 de 07 de 2012 a les 17:22 +0200, en/na Piotr Drąg va escriure: > 2012/7/18 GNOME Status Pages : > > This is an automatic notification from status generation scripts on: > > http://l10n.gnome.org. > > > > There have been following string additions to module > > 'glib-networking.master': > > > > + "Connection is already closed" > > + "Connection is closed" > > + "Operation would block" > > + "Server did not return a valid TLS certificate" > > > > Could you please switch GNOME 3.4's glib-networking to glib-2-32 > branch and 3.2's to glib-2-30? > > Thanks in advance, > So, I changed it on l10n.gnome.org like that: GNOME3.6: glib-networking (master) GNOME3.4: glib-networking (glib-2-32) (that's the only change I made actually) GNOME3.2: glib-networking (glib-2-30) Cheers, -- 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 planet: http://planet.guifi.net ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'glib-networking.master'
2012/7/18 GNOME Status Pages : > This is an automatic notification from status generation scripts on: > http://l10n.gnome.org. > > There have been following string additions to module 'glib-networking.master': > > + "Connection is already closed" > + "Connection is closed" > + "Operation would block" > + "Server did not return a valid TLS certificate" > Could you please switch GNOME 3.4's glib-networking to glib-2-32 branch and 3.2's to glib-2-30? Thanks in advance, -- Piotr Drąg http://raven.fedorapeople.org/ ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions to 'glib-networking.master'
This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'glib-networking.master': + "Connection is already closed" + "Connection is closed" + "Operation would block" + "Server did not return a valid TLS certificate" Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. http://git.gnome.org/browse/glib-networking/log/?h=master ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'glib-networking.master'
Le vendredi 04 novembre 2011 à 23:16 +0100, Gil Forcada a écrit : > El dv 04 de 11 de 2011 a les 16:19 +, en/na GNOME Status Pages va > escriure: > > This is an automatic notification from status generation scripts on: > > http://l10n.gnome.org. > > > > There have been following string additions to module > > 'glib-networking.master': > > > > + "Module" > > + "PKCS#11 Module Pointer" > > + "PKCS#11 Slot Identifier" > > + "Several PIN attempts have been incorrect, and the token will be > > locked after further failures." > > + "Slot ID" > > + "The PIN entered is incorrect." > > + "This is the last chance to enter the PIN correctly before the token > > is locked." > > > > Note that this doesn't directly indicate a string freeze break, but it > > might be worth investigating. > > It seems that they already created a stable branch (glib-2-30 just like > glib). Should we put that branch on GNOME 3.2 release set? Sure, thanks for the tip. Maintainers, as branches that do not start with gnome are not automatically announced on the list, it would be nice to send a notice to gnome-i18n when this module branches. Thanks! Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'glib-networking.master'
El dv 04 de 11 de 2011 a les 16:19 +, en/na GNOME Status Pages va escriure: > This is an automatic notification from status generation scripts on: > http://l10n.gnome.org. > > There have been following string additions to module 'glib-networking.master': > > + "Module" > + "PKCS#11 Module Pointer" > + "PKCS#11 Slot Identifier" > + "Several PIN attempts have been incorrect, and the token will be locked > after further failures." > + "Slot ID" > + "The PIN entered is incorrect." > + "This is the last chance to enter the PIN correctly before the token is > locked." > > Note that this doesn't directly indicate a string freeze break, but it > might be worth investigating. It seems that they already created a stable branch (glib-2-30 just like glib). Should we put that branch on GNOME 3.2 release set? Cheers, > ___ > 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 planet: http://planet.guifi.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions to 'glib-networking.master'
This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'glib-networking.master': + "Module" + "PKCS#11 Module Pointer" + "PKCS#11 Slot Identifier" + "Several PIN attempts have been incorrect, and the token will be locked after further failures." + "Slot ID" + "The PIN entered is incorrect." + "This is the last chance to enter the PIN correctly before the token is locked." Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
GLib 2.30 branch
hi,
GLib has branched for the stable release ('glib-2-30'). All translation
effort should be focused there (since this is what will appear in GNOME
3.2).
The branch is to be considered frozen for code changes, except by
approval.
Thanks
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Modified translations in GLib
Right, I agree with you since your comment says that Glib is using kb to mean 1000 bytes, instead of 1024, so this patch is correct. Many thanks for your help and sorry for not answering you 2011/8/31 Ryan Lortie > hi Daniel, > > On Mon, 2011-07-25 at 12:04 +0200, Daniel Mustieles García wrote: > > The spanish team usually translates this term as "MiB" but, > > sincerelly, I don't remember exactly the reason :-$ > > > > I've asked our team coordinator about it, because if we change it in > > glib, we should review an change this translation in the other > > modules, so I'd like to be really sure it is correct before doing the > > work. > > > > When Jorge answer me, I'll notice you > > After waiting a while to hear back, I noticed that the Spanish > translation was still incorrect so I committed a fix[1]. > > Cheers > > [1] > http://git.gnome.org/browse/glib/commit/?id=dab38147aec8bd415a6816422baa59863c941ead > > > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Modified translations in GLib
hi Daniel, On Mon, 2011-07-25 at 12:04 +0200, Daniel Mustieles García wrote: > The spanish team usually translates this term as "MiB" but, > sincerelly, I don't remember exactly the reason :-$ > > I've asked our team coordinator about it, because if we change it in > glib, we should review an change this translation in the other > modules, so I'd like to be really sure it is correct before doing the > work. > > When Jorge answer me, I'll notice you After waiting a while to hear back, I noticed that the Spanish translation was still incorrect so I committed a fix[1]. Cheers [1] http://git.gnome.org/browse/glib/commit/?id=dab38147aec8bd415a6816422baa59863c941ead ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [glib] String Change Announcement
On 08/30/2011 07:07 PM, Tomas Bzatek wrote: > Hi, > > I've just pushed this tiny change in glib, fixing the English grammar a > little. I guess this change only affects English-related translations, > such as en_US -> en_GB etc. > > http://git.gnome.org/browse/glib/commit/?id=116b2932abfa7727cd0486e6e74624aaf4012ab7 > Hi, FYI: any change in original message affects all translations: translators are forced to remove fuzzy mark for modified messages. /Ihar ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[glib] String Change Announcement
Hi, I've just pushed this tiny change in glib, fixing the English grammar a little. I guess this change only affects English-related translations, such as en_US -> en_GB etc. http://git.gnome.org/browse/glib/commit/?id=116b2932abfa7727cd0486e6e74624aaf4012ab7 -- Tomas Bzatek ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Modified translations in GLib
Hi Ryan, The spanish team usually translates this term as "MiB" but, sincerelly, I don't remember exactly the reason :-$ I've asked our team coordinator about it, because if we change it in glib, we should review an change this translation in the other modules, so I'd like to be really sure it is correct before doing the work. When Jorge answer me, I'll notice you 2011/7/21 Ryan Lortie > hi Daniel, > > I see that you recently made this commit against GLib: > > > http://git.gnome.org/browse/glib/commit/?id=e43a2969114e91332b127a479bcb078be6649353 > > shortly after I made some related changes to the Spanish translation. > Your changes essentially reversed my changes. > > The reason I made the changes is explained in an email I sent to > gnome-i18n list, included below. > > In effect, GLib now uses "MB" to really mean "one million bytes" (and > same with the other units). It is no longer at all appropriate to > translate these strings into "MiB", etc. The SI units should be used. > > Cheers > > On Wed, 2011-07-20 at 20:16 +0200, Ryan Lortie wrote: > > hi i18n, > > > > I'm writing as a heads-up to let you know that I took the liberty of > > modifying some translations in GLib. > > > > I include the commit log from the change, because it describes the > > situation reasonably well. > > > > commit ef3e5917ca1239b39db2cb433c4306d0152f18f5 > > Author: Ryan Lortie > > Date: Wed Jul 20 19:58:43 2011 +0200 > > > > [ast, es, fr, nn] Update byte unit translations > > > > The Asturian, French, Norwegian Nynorsk and Spanish translations > > incorrectly translated "MB" and friends to "MiB" (french: "Mio"), > etc. > > > > This was in response to the incorrect use of "MB" in the (now > > deprecated) g_format_size_for_display() function. > > > > These strings are now used (correctly) in g_format_size(), so I have > > updated the translations accordingly. > > > > Additionally, the Norwegian Nynorsk translation was incorrectly > > translating several larger units to "KiB", so that has been corrected > as > > well. > > > > There are some translations (ie: those into non-Latin-charset languages) > > for which I was unable to tell if a change was appropriate. Those > > maintainers should probably take a look. > > > > > > Cheers > > > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Modified translations in GLib
Le mercredi 20 juillet 2011 à 20:16 +0200, Ryan Lortie a écrit : > hi i18n, > > I'm writing as a heads-up to let you know that I took the liberty of > modifying some translations in GLib. > > I include the commit log from the change, because it describes the > situation reasonably well. Thanks Ryan, this change is warmly welcome \o/ Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Modified translations in GLib
hi Daniel, I see that you recently made this commit against GLib: http://git.gnome.org/browse/glib/commit/?id=e43a2969114e91332b127a479bcb078be6649353 shortly after I made some related changes to the Spanish translation. Your changes essentially reversed my changes. The reason I made the changes is explained in an email I sent to gnome-i18n list, included below. In effect, GLib now uses "MB" to really mean "one million bytes" (and same with the other units). It is no longer at all appropriate to translate these strings into "MiB", etc. The SI units should be used. Cheers On Wed, 2011-07-20 at 20:16 +0200, Ryan Lortie wrote: > hi i18n, > > I'm writing as a heads-up to let you know that I took the liberty of > modifying some translations in GLib. > > I include the commit log from the change, because it describes the > situation reasonably well. > > commit ef3e5917ca1239b39db2cb433c4306d0152f18f5 > Author: Ryan Lortie > Date: Wed Jul 20 19:58:43 2011 +0200 > > [ast, es, fr, nn] Update byte unit translations > > The Asturian, French, Norwegian Nynorsk and Spanish translations > incorrectly translated "MB" and friends to "MiB" (french: "Mio"), etc. > > This was in response to the incorrect use of "MB" in the (now > deprecated) g_format_size_for_display() function. > > These strings are now used (correctly) in g_format_size(), so I have > updated the translations accordingly. > > Additionally, the Norwegian Nynorsk translation was incorrectly > translating several larger units to "KiB", so that has been corrected as > well. > > There are some translations (ie: those into non-Latin-charset languages) > for which I was unable to tell if a change was appropriate. Those > maintainers should probably take a look. > > > Cheers ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Modified translations in GLib
hi i18n, I'm writing as a heads-up to let you know that I took the liberty of modifying some translations in GLib. I include the commit log from the change, because it describes the situation reasonably well. commit ef3e5917ca1239b39db2cb433c4306d0152f18f5 Author: Ryan Lortie Date: Wed Jul 20 19:58:43 2011 +0200 [ast, es, fr, nn] Update byte unit translations The Asturian, French, Norwegian Nynorsk and Spanish translations incorrectly translated "MB" and friends to "MiB" (french: "Mio"), etc. This was in response to the incorrect use of "MB" in the (now deprecated) g_format_size_for_display() function. These strings are now used (correctly) in g_format_size(), so I have updated the translations accordingly. Additionally, the Norwegian Nynorsk translation was incorrectly translating several larger units to "KiB", so that has been corrected as well. There are some translations (ie: those into non-Latin-charset languages) for which I was unable to tell if a change was appropriate. Those maintainers should probably take a look. Cheers ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[couchdb-glib] Created branch gnome-3-0
The branch 'gnome-3-0' was created pointing to: bada58e... Use SoupSessionAsync instead of SoupSessionSync ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[couchdb-glib] Created branch gnome-2-32
The branch 'gnome-2-32' was created pointing to: cc898a1... Use silent building if available ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: [glib] GLib has branched
Le samedi 18 septembre 2010 à 10:23 -0400, Ryan Lortie a écrit : > Hello, > > I branched glib yesterday, creating the 'glib-2-26' branch. That's for > the upcoming glib 2.26.0 that will go into GNOME 2.32. The strings on > this branch should not be changing very much anymore. > > 'master' branch is what will eventually become glib 2.28.0 as part of > GNOME 3. > > Thanks, and Cheers Thanks for informing us! l10n.gnome.org updated. Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[glib] GLib has branched
Hello, I branched glib yesterday, creating the 'glib-2-26' branch. That's for the upcoming glib 2.26.0 that will go into GNOME 2.32. The strings on this branch should not be changing very much anymore. 'master' branch is what will eventually become glib 2.28.0 as part of GNOME 3. Thanks, and Cheers ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
string change in glib
Hey,
I have just fixed https://bugzilla.gnome.org/show_bug.cgi?id=629429
which involved changing a bunch of msgctxts in glib. I have updated
all existing translations, so there should be minimal fallout for
translators, except for the new untranslated string
msgctxt "abbreviated month name"
msgid "May"
Matthias
PS This is the sed script I used, if you are interested:
/msgctxt "GDateTime"/{
N
s/msgctxt "GDateTime"\nmsgid
"\(January\|February\|March\|April\|May\|June\|July\|August\|September\|October\|November\|December\)"/msgctxt
"full month name"\
msgid "\1"/
s/msgctxt "GDateTime"\nmsgid
"\(Jan\|Feb\|Mar\|Apr\|Jun\|Jul\|Aug\|Sep\|Oct\|Nov\|Dec\)"/msgctxt
"abbreviated month name"\
msgid "\1"/
s/msgctxt "GDateTime"\nmsgid
"\(Monday\|Tuesday\|Wednesday\|Thursday\|Friday\|Saturday\|Sunday\)"/msgctxt
"full weekday name"\
msgid "\1"/
s/msgctxt "GDateTime"\nmsgid
"\(Mon\|Tue\|Wed\|Thu\|Fri\|Sat\|Sun\)"/msgctxt "abbreviated weekday
name"\
msgid "\1"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
String changes in GLib
Hi all, I've just pushed a few string changes to GLib for https://bugzilla.gnome.org/show_bug.cgi?id=628193 in these commits: http://git.gnome.org/browse/glib/commit/?id=ea9f5f025188731f4347f5be1248e84dc3710c7b http://git.gnome.org/browse/glib/commit/?id=1399913f31b60ffebb84e08d8901e82aab2bb075 Note that there may well be more string changes from that bug before the string freeze on Monday! Thanks, Philip ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New strings in gtk+ and glib
Le vendredi 27 août 2010 à 20:07 +0200, Claude Paroz a écrit : > Hi, > > As part of a POTFILES.in-fixing campaign, there are new strings in GTK+ > po-properties and glib. ...and I also just updated GTK+ to use the gtk-2-22 branch for GNOME 2.32 Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
New strings in gtk+ and glib
Hi, As part of a POTFILES.in-fixing campaign, there are new strings in GTK+ po-properties and glib. Cheers, Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[couchdb-glib] Created branch gnome-2-30
The branch 'gnome-2-30' was created pointing to: 01b7663... Remove extra ; ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
[couchdb-glib] Created branch gnome-2-28
The branch 'gnome-2-28' was created pointing to: e7b2a28... Release 0.5.1 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GLib branched for 2.20
Le samedi 18 avril 2009 à 15:38 -0400, Matthias Clasen a écrit : > I've just created a glib-2-20 branch. Please commit stable bug fixes > there. master is now open for development towards 2.22. Further 2.20.x > releases will be made off the glib-2-20 branch. Thanks, l10n.gnome.org updated. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
GLib branched for 2.20
I've just created a glib-2-20 branch. Please commit stable bug fixes there. master is now open for development towards 2.22. Further 2.20.x releases will be made off the glib-2-20 branch. Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
2009/4/6 Kristian Høgsberg : > On Fri, 2009-04-03 at 02:28 +0200, Philipp wrote: >> >> >> Kristian Høgsberg wrote: >> > Just an update on my plan to possibly rebase the gtk+ repo: not going to >> > happen. What we have now is a good compromise between keeping all >> > history in the most correct form and how much work we want to put into >> > it. Again, no data is lost, we just have a few tags with some extra >> > files in them. >> How about deleting the broken tags from the git repos and keeping a >> little note somewhere buried deep in the docs/ dirs. Someone who cares >> about digging through history (like me) will then know to hit the >> historical CVS / SVN repositories for these specific missing tags. >> >> Its not like someone is going to re-roll tarballs from these tags ever >> again (or at least the chance is ~ ɛ). > > I don't see a good reason to delete the tags. They take virtually no > storage, and are mostly accurate except for the extra files. Last but > not least, they're a great help when browsing through history since most > repo viewers will annotate commits with the tag or branch if one or more > exists (for example, the GTK_2_16_0 tag on this page: > http://git.gnome.org/cgit/gtk+/log/?ofs=50) It would be better if you used more git compliant tags like "v2.16.0". Those tags make sense, but "BEFORE_FEDERICO_FILENAME_ENTRY_MERGE"... I don't think so. -- Felipe Contreras ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Upgrade of gettext on git.gnome.org (was Re: Moving GLib and GTK+ to git)
On Thu, 2009-04-02 at 16:56 -0400, Owen Taylor wrote: > On Thu, 2009-04-02 at 22:45 +0200, Olav Vitters wrote: > > On Thu, Apr 02, 2009 at 12:07:30PM +0200, Alexander Larsson wrote: > > > I've got a local branch with the rebased client-side-windows work. > > > However, I am unable to push it to git.gnome.org due to the pre-commit > > > hooks: > > > > > > The following translation (.po) file appears to be invalid. (When > > > updating branch 'client-side-windows'.) > > > po/af.po > > > The results of the validation follow. Please correct the errors on the > > > line numbers mentioned and try to push again. > > > :90: keyword "msgctxt" unknown > > > :90:8: parse error > > > . > > > > > > > > > Checking > > > http://git.gnome.org/cgit/gitadmin-bin/tree/pre-receive-check-po we > > > have: > > > > > > # gettext-0.14.6 on git.gnome.org isn't new enough to handle > > > # features such as msgctx > > > # dash_c="-c" > > > dash_c= > > > > So a gettext update should be done. CC'ed gnome-sysadmin. > > Upgrading the system gettext to a radically different version isn't > something that I want to do. My plan here is to create an RPM with just > the gettext utilities that installs in /usr/lib/gettext17 or something. > > (BTW, I temporarily disabled the hooks so Alex could push his branch.) I've now gone ahead and done this - there is a statically linked version of gettext-0.17 in /usr/libexec/gettext17 that the pre-receive check uses now. I've also reeneabled -c, so it should be doing a full set of checks. Let me know if any problems show up. - Owen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
Edward Hervey schrieb: > On Tue, 2009-03-31 at 21:29 +0200, Martin Nordholts wrote: > >> Matthias Clasen wrote: >> >>> - First line (the brief description) must only be one sentence and >>>must not start with a capital letter. Don't use a trailing period >>>either. Don't exceed 76 characters. >>> >> Hi, >> >> Is there any particular reason for not starting with a capital letter, >> e.g. are there any tools that depend on it? In general I think a >> sentence look nicer if it starts with a capital letter, including those >> that does not end with a period. From a quick look at the most recent >> commit messages for the Linux kernel and git itself, it does not seem as >> if they have a rule such as the one above, which makes me even more >> curious why we should have it. >> > > FWIW, In GStreamer git repositories we use that same rule for the > one-liner with a subtle variation: > * We do allow capital letters (seriously, who cares? It looks nice) > * Considering you want to have as much info as possible in that > one-liner, we try to prefix it with a word giving a clue as to where the > work was done (without looking at the modified files). Doesn't apply if > it's a change accross the whole module. > Ex : >"rtspsrc: allow http:// on the proxy setting", or >"Mark unused arguments using G_GNUC_UNUSED glib macro." > > Edward > And we have a script to generate the ChangeLog for releases in gst too, right? Stefan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
On Fri, 2009-04-03 at 02:28 +0200, Philipp wrote: > > > Kristian Høgsberg wrote: > > Just an update on my plan to possibly rebase the gtk+ repo: not going to > > happen. What we have now is a good compromise between keeping all > > history in the most correct form and how much work we want to put into > > it. Again, no data is lost, we just have a few tags with some extra > > files in them. > How about deleting the broken tags from the git repos and keeping a > little note somewhere buried deep in the docs/ dirs. Someone who cares > about digging through history (like me) will then know to hit the > historical CVS / SVN repositories for these specific missing tags. > > Its not like someone is going to re-roll tarballs from these tags ever > again (or at least the chance is ~ ɛ). I don't see a good reason to delete the tags. They take virtually no storage, and are mostly accurate except for the extra files. Last but not least, they're a great help when browsing through history since most repo viewers will annotate commits with the tag or branch if one or more exists (for example, the GTK_2_16_0 tag on this page: http://git.gnome.org/cgit/gtk+/log/?ofs=50) cheers, Kristian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
On Fri, Apr 3, 2009 at 10:04 AM, Edward Hervey wrote: > On Tue, 2009-03-31 at 21:29 +0200, Martin Nordholts wrote: >> Matthias Clasen wrote: >> > - First line (the brief description) must only be one sentence and >> > must not start with a capital letter. Don't use a trailing period >> > either. Don't exceed 76 characters. >> >> Hi, >> >> Is there any particular reason for not starting with a capital letter, >> e.g. are there any tools that depend on it? In general I think a >> sentence look nicer if it starts with a capital letter, including those >> that does not end with a period. From a quick look at the most recent >> commit messages for the Linux kernel and git itself, it does not seem as >> if they have a rule such as the one above, which makes me even more >> curious why we should have it. > > FWIW, In GStreamer git repositories we use that same rule for the > one-liner with a subtle variation: > * We do allow capital letters (seriously, who cares? It looks nice) > * Considering you want to have as much info as possible in that > one-liner, we try to prefix it with a word giving a clue as to where the > work was done (without looking at the modified files). Doesn't apply if > it's a change accross the whole module. > Ex : > "rtspsrc: allow http:// on the proxy setting", or > "Mark unused arguments using G_GNUC_UNUSED glib macro." This is also the guideline used in git.git, and it looks pretty good: id: fix foobar or if there's no id: Generic cleanup Note that no full-stop is used. -- Felipe Contreras ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
Kristian Høgsberg wrote: > Just an update on my plan to possibly rebase the gtk+ repo: not going to > happen. What we have now is a good compromise between keeping all > history in the most correct form and how much work we want to put into > it. Again, no data is lost, we just have a few tags with some extra > files in them. How about deleting the broken tags from the git repos and keeping a little note somewhere buried deep in the docs/ dirs. Someone who cares about digging through history (like me) will then know to hit the historical CVS / SVN repositories for these specific missing tags. Its not like someone is going to re-roll tarballs from these tags ever again (or at least the chance is ~ ɛ). Ciao, Philipp ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
On 04/03/2009 03:04 AM, Edward Hervey wrote: FWIW, In GStreamer git repositories we use that same rule for the one-liner with a subtle variation: * We do allow capital letters (seriously, who cares? It looks nice) * Considering you want to have as much info as possible in that one-liner, we try to prefix it with a word giving a clue as to where the work was done (without looking at the modified files). Doesn't apply if it's a change accross the whole module. Ex : "rtspsrc: allow http:// on the proxy setting", or "Mark unused arguments using G_GNUC_UNUSED glib macro." Right. In cairo and pango we do the same, with a slightly different syntax. For example: [win32] Fix horizontal glyph positioning bug [test] Memfault checks [surface] Propagate region allocation failure [traps] Propagate allocation failure [region] Use const cairo_rectangle_int_t consistently [scaled-font] Global glyph cache I find that quite useful. behdad Edward BR, Martin ___ 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 21:29 +0200, Martin Nordholts wrote: > Matthias Clasen wrote: > > - First line (the brief description) must only be one sentence and > >must not start with a capital letter. Don't use a trailing period > >either. Don't exceed 76 characters. > > Hi, > > Is there any particular reason for not starting with a capital letter, > e.g. are there any tools that depend on it? In general I think a > sentence look nicer if it starts with a capital letter, including those > that does not end with a period. From a quick look at the most recent > commit messages for the Linux kernel and git itself, it does not seem as > if they have a rule such as the one above, which makes me even more > curious why we should have it. FWIW, In GStreamer git repositories we use that same rule for the one-liner with a subtle variation: * We do allow capital letters (seriously, who cares? It looks nice) * Considering you want to have as much info as possible in that one-liner, we try to prefix it with a word giving a clue as to where the work was done (without looking at the modified files). Doesn't apply if it's a change accross the whole module. Ex : "rtspsrc: allow http:// on the proxy setting", or "Mark unused arguments using G_GNUC_UNUSED glib macro." Edward > > BR, > Martin > ___ > 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: Upgrade of gettext on git.gnome.org (was Re: Moving GLib and GTK+ to git)
On Thu, 2009-04-02 at 22:45 +0200, Olav Vitters wrote: > On Thu, Apr 02, 2009 at 12:07:30PM +0200, Alexander Larsson wrote: > > I've got a local branch with the rebased client-side-windows work. > > However, I am unable to push it to git.gnome.org due to the pre-commit > > hooks: > > > > The following translation (.po) file appears to be invalid. (When > > updating branch 'client-side-windows'.) > > po/af.po > > The results of the validation follow. Please correct the errors on the > > line numbers mentioned and try to push again. > > :90: keyword "msgctxt" unknown > > :90:8: parse error > > . > > > > > > Checking > > http://git.gnome.org/cgit/gitadmin-bin/tree/pre-receive-check-po we > > have: > > > > # gettext-0.14.6 on git.gnome.org isn't new enough to handle > > # features such as msgctx > > # dash_c="-c" > > dash_c= > > So a gettext update should be done. CC'ed gnome-sysadmin. Upgrading the system gettext to a radically different version isn't something that I want to do. My plan here is to create an RPM with just the gettext utilities that installs in /usr/lib/gettext17 or something. (BTW, I temporarily disabled the hooks so Alex could push his branch.) - Owen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Upgrade of gettext on git.gnome.org (was Re: Moving GLib and GTK+ to git)
On Thu, Apr 02, 2009 at 12:07:30PM +0200, Alexander Larsson wrote: > I've got a local branch with the rebased client-side-windows work. > However, I am unable to push it to git.gnome.org due to the pre-commit > hooks: > > The following translation (.po) file appears to be invalid. (When > updating branch 'client-side-windows'.) > po/af.po > The results of the validation follow. Please correct the errors on the > line numbers mentioned and try to push again. > :90: keyword "msgctxt" unknown > :90:8: parse error > . > > > Checking > http://git.gnome.org/cgit/gitadmin-bin/tree/pre-receive-check-po we > have: > > # gettext-0.14.6 on git.gnome.org isn't new enough to handle > # features such as msgctx > # dash_c="-c" > dash_c= So a gettext update should be done. CC'ed gnome-sysadmin. -- Regards, Olav ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
Matthias Clasen wrote: > - First line (the brief description) must only be one sentence and >must not start with a capital letter. Don't use a trailing period >either. Don't exceed 76 characters. Hi, Is there any particular reason for not starting with a capital letter, e.g. are there any tools that depend on it? In general I think a sentence look nicer if it starts with a capital letter, including those that does not end with a period. From a quick look at the most recent commit messages for the Linux kernel and git itself, it does not seem as if they have a rule such as the one above, which makes me even more curious why we should have it. BR, Martin ___ 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: > 2009/3/31 Kristian Høgsberg : > > > > > 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. Just an update on my plan to possibly rebase the gtk+ repo: not going to happen. What we have now is a good compromise between keeping all history in the most correct form and how much work we want to put into it. Again, no data is lost, we just have a few tags with some extra files in them. So unless we find a show-stopper bug in the import within the next few days, what's on git.gnome.org now is final. cheers, Kristian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
On Mon, 2009-03-30 at 12:47 -0400, Matthias Clasen wrote: > Last week, I said that I'd like to get this done by the end of March, > which is almost upon us now. > > Therefore, I'd like to ask everybody to hold off with committing to > svn. While we are not quite ready to start the migration yet, it will > begin sometime later today. So to avoid duplicate work, it would be > best to wait with further commits to glib and gtk+ until the migration > is completed. I'll send another email with checkout information, etc, > when the conversion is done. The glib and gtk+ repositories are up now and they are live: http://git.gnome.org/cgit/glib http://git.gnome.org/cgit/gtk+ and I've been verifying that master and all tags are identical between git and svn. There are some differences for some of the older cvs tags, but it looks like they break down into two cases: 1) CVS tagging races with a commit: person A does cvs up, cvs commit, make dist, person B does cvs commit, A does cvs commit, and gets no conflicts with person B's commit, then does cvs tag. The tag now references files from before the B commit and file from after the B commit. This is possible with CVS and SVN can represent it by breaking the svn cp for the tag into a piece-wise copy from different revisions. With git, a tag just points to a existing commit, so to do this, we'd have to create a commit that matches what the cvs tag contains. Check out 1.3.12 for an example. It's only a problem for a few old cvs era commits and the effect is that the git tag will contain a commit that wasn't in the tarball or cvs tag. It won't affect other parts of history, specifically, git blame information is still accurate. I've talked with Owen and Matthias about it and we don't feel it's an issue that's worth tackling. 2) CVS repos that were copied into the gtk+ repo on the server. Three main cases are gdk-pixbuf, the reference docs and the pixbuf theme engine. These were all either started as their own cvs repo or part of another repo. The RCS (the ,v files) were copied on the server to pull them into gtk+ with full history. CVS implements tagging by tagging every RCS file, so every RCS contains all the tags from the repo, and when you move an RCS file, the tags move with it. Git doesn't support tagging just a sub-directory so what the CVS to git importer does in this case is to expand the tag to cover the entire tree. This means that a gdk-pixbuf tag from when it was an independent repo will now include gtk+ files in it and vice versa. The consequence is that checking out an old gtk+ tag from before gdk-pixbuf (or the docs or the pixbuf theme engine) got merged may have the gdk-pixbuf files in it. Again, this only affects older CVS tags, doesn't throw away information and most important, doesn't affect git blame output. Ideally we could split out the gdk-pixbuf history from before the RCS files got copied into a branch with a different initial commit and create a merge commit where the two histories join. I'm going to take a couple of hours to look at this, but I suspect it may not doable with reasonable effort. I mean, this theory is nice and all, but when it comes down to the nitty-gritty shell-quoting details of making it actually work I may end up concluding that it's just not practical. So, with the caveat that we might rebase the gtk+ repo, glib and gtk+ are now in git! If we end up getting a fix for 2), we'll rebase and replay whatever commits happened in the meantime to the rebased tree. If you don't know what to do if an upstream repo rebases, it's probably best to hold off committing to the git repos a little longer. Other than that I'd say we're ready to go, but I'll leave it to Matthias to make the call. cheers, Kristian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
On Mon, 2009-03-30 at 12:47 -0400, Matthias Clasen wrote: > Last week, I said that I'd like to get this done by the end of March, > which is almost upon us now. I've got a local branch with the rebased client-side-windows work. However, I am unable to push it to git.gnome.org due to the pre-commit hooks: The following translation (.po) file appears to be invalid. (When updating branch 'client-side-windows'.) po/af.po The results of the validation follow. Please correct the errors on the line numbers mentioned and try to push again. :90: keyword "msgctxt" unknown :90:8: parse error . Checking http://git.gnome.org/cgit/gitadmin-bin/tree/pre-receive-check-po we have: # gettext-0.14.6 on git.gnome.org isn't new enough to handle # features such as msgctx # dash_c="-c" dash_c= This means whats currently in gtk+ master branch does not pass the commit checks, so we can't branch master even if no changes are made to the pofiles. Also, it means we can't do updates to the pofiles in master that uses msgctxt. ___ 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 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
Re: Moving GLib and GTK+ to git
On Tue, Mar 31, 2009 at 3:58 PM, 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. 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 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, 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 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
Hi, On Tue, 2009-03-31 at 21:29 +0200, Martin Nordholts wrote: > Matthias Clasen wrote: > > - First line (the brief description) must only be one sentence and > >must not start with a capital letter. Don't use a trailing period > >either. Don't exceed 76 characters. (Btw, should probably say 72 characters so 'git log | git shortlog' output is bounded to 80 characters so it's bearable to look at in a normal terminal; see below for details.) > > Hi, > > Is there any particular reason for not starting with a capital letter, > e.g. are there any tools that depend on it? In general I think a > sentence look nicer if it starts with a capital letter, including those > that does not end with a period. From a quick look at the most recent > commit messages for the Linux kernel and git itself, it does not seem as > if they have a rule such as the one above, which makes me even more > curious why we should have it. I think it's just about consistency (having some commits start with a non-capital and some start with a capital looks weird; ditto for trailing periods) not so much about about a preference on whether it should be non-capital/capital. 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. 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
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 : > > > > > 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: Moving GLib and GTK+ to git
On 03/31/2009 03:05 PM, Matthias Clasen wrote: 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. I'll figure out what to do about autogenerating ChangeLogs in release tarballs in time for the next releases... Feel free to copy from Pango. Pango only has one ChangeLog though. You may want to consolidate gtk's many ones now. The one deviation in this from our current ChangeLog entry style is that it moves the bug reference from the short explanation to the main description. I'm not entirely sure which is better here, a little experimentation may be needed to come up with the best style. For Pango I continue to use the bug title line as my short summary. If needed, I retitle the bug first. For example: commit cf13cde8a80c9a1a9d4c9e343c634350da59991a Author: Behdad Esfahbod Date: Thu Mar 26 01:03:43 2009 -0400 Bug 571291 – Unicode 5.1 support in pango - Indic Lanuages Add char class for new characters. Patch from Rahul Bhalerao. commit 477747bc1ef1078b06c4e1c615a1a912e6ada299 Author: Sebastian Dröge Date: Mon Mar 23 19:16:58 2009 -0400 Bug 576298 – Fails to link pango-view if --without-x is specified but cairo has X11 support commit c82e8ad9dda142b1acfbcb86054750e082600893 Author: Behdad Esfahbod Date: Mon Mar 16 17:25:33 2009 -0400 Bug 547963 – man page for pango-view commit 69e1f7921525c2849d937b5a822475007a4f9a2f Author: Behdad Esfahbod Date: Mon Mar 16 16:57:58 2009 -0400 Bug 502804 – pango-view or pangocairo-view option to annotate Added --annotate. Also fixes: Bug 502801 – per-backend pango-view options behdad ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
I should have also mentioned that the commands you need are: git clone git://git.gnome.org/glib git clone git://git.gnome.org/gtk+ A lot more information about the git migration and git in general can be found at http://live.gnome.org/GitMigration. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Moving GLib and GTK+ to git
2009/3/31 Kristian Høgsberg : > > 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 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. I'll figure out what to do about autogenerating ChangeLogs in release tarballs in time for the next releases... Commit messages: Here are some recommendations that I think meet our needs: === begin example commit === short explanation of the commit Longer explanation explaining exactly what's changed, whether any external or private interfaces changed, what bugs were fixed (with bug tracker reference if applicable) and so forth. Be concise but not too brief. === end example commit === - Always add a brief description of the commit to the _first_ line of the commit and terminate by two newlines (it will work without the second newline, but that is not nice for the interfaces). - First line (the brief description) must only be one sentence and must not start with a capital letter. Don't use a trailing period either. Don't exceed 76 characters. - The main description (the body) is normal prose and should use normal punctuation and capital letters where appropriate. Normally, for patches sent to a mailing list it's copied from there. - When committing code on behalf of others use the --author option, e.g. git commit -a --author "Joe Coder " and --signoff. The one deviation in this from our current ChangeLog entry style is that it moves the bug reference from the short explanation to the main description. I'm not entirely sure which is better here, a little experimentation may be needed to come up with the best style. 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. I'll work on updating README.commits and similar files. Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Moving GLib and GTK+ to git
Last week, I said that I'd like to get this done by the end of March, which is almost upon us now. Therefore, I'd like to ask everybody to hold off with committing to svn. While we are not quite ready to start the migration yet, it will begin sometime later today. So to avoid duplicate work, it would be best to wait with further commits to glib and gtk+ until the migration is completed. I'll send another email with checkout information, etc, when the conversion is done. See you all on the other side ! Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Unusual wording in glib HEAD
Hi Mișu, On Tue, 2009-03-03 at 22:59 +0200, Mișu Moldovan wrote: > Hi, > > Can a native English speaker with a clue check if the following string > from glib makes sense? > > #: ../gio/gicon.c:469 > msgid "Can't handle the supplied version the icon encoding" > > My instincts tell me to translate it as if it means: > > msgid "Can't handle the supplied version *of* the icon encoding" That looks correct to me, and it's what I've used in the British English translation. Regards, Philip > Any opinion? > > Thanks, > > ___ > gnome-i18n mailing list > gnome-i18n@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-i18n 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: Unusual wording in glib HEAD
2009-03-03 klockan 21:59 skrev Mișu Moldovan: > Can a native English speaker with a clue check if the following string > from glib makes sense? > #: ../gio/gicon.c:469 > msgid "Can't handle the supplied version the icon encoding" > My instincts tell me to translate it as if it means: > msgid "Can't handle the supplied version *of* the icon encoding" This is obviously a mistake in the original string, since it's nongrammatical. CC'ing Alex. Alex, can you deal with this (please replace the msgid lines in all .po files)? Thanks! — Wouter signature.asc Description: Digital signature ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Unusual wording in glib HEAD
Hi, Can a native English speaker with a clue check if the following string from glib makes sense? #: ../gio/gicon.c:469 msgid "Can't handle the supplied version the icon encoding" My instincts tell me to translate it as if it means: msgid "Can't handle the supplied version *of* the icon encoding" Any opinion? Thanks, -- mișu pgp98gtGQy5bu.pgp Description: PGP signature ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GLib has been branched
Le jeudi 18 septembre 2008 à 10:50 -0400, Matthias Clasen a écrit : > I have just created a glib-2-18 branch. Further stable 2.18.x releases > will be made from that branch, while trunk receives new development > towards 2.20. Thanks, l10n.gnome.org updated. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
GLib has been branched
I have just created a glib-2-18 branch. Further stable 2.18.x releases will be made from that branch, while trunk receives new development towards 2.20. Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
