GNOME Bugzilla – Bug 482769
Gedit Spell checker plugin uses external messages (from iso_codes)
Last modified: 2019-03-23 20:47:34 UTC
Please describe the problem: It's weird that Gedit uses messages for its Spell checker that are not available for GNOME release translators. I think we either should not use them or make sure Gedit uses our "local" GNOME copy of these message catalogs from iso_codes package. There is also the problem with miss-synchronization of GNOME and iso_codes releases, and it's hard to maintain such situation. Ihar Hrachyshka, Belarusian i18n coordinator Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
I am not sure I understand... using iso_codes was an explicit request of translators and is used to translate language names ("Italian", "English", and so on) since translations of those words is a huge work and it would be silly to repeat it everywhere. For the same reason the iso_codes package is also used in other parts of gnome (epiphany comes to my mind).
At first, I don't think it's some kind of RIGHT thing. Because it means we explicitly ground our work on the external l10n efforts that are not controlled by our l10n teams. And if I, as a coordinator of GNOME Belarusian l10n, get bug-reports about wrong (btw automatically and weirdly generated) messages in Gedit (and that's not "just a problem" because for now we have "belarusian" translation of the message containing "Belarusian" that is widely considered by Belarusian folks as obscure and abuse form), then I try to locate where is the problem IN GNOME PACKAGES. And then I need to fix the problem ASAP, and not waiting for long terms of releasing new version of iso_codes. More then: I can't find the place for bug reporting about problems in iso_codes. Anyway, can we at least add this iso_codes package to Freedesktop.org (non-GNOME) packages to make sure our translators can monitor the status of these messages' translation and make sure that the process of such packages' i18n is as easy as possible? PS: As for our community, we would be glad to see iso_codes "fork" that is periodically synced with upstream, f.e., for every new GNOME release.
Hi BooXteR, I think you should discuss this problem with the rest of the gnome-i18n team on the gnome-i18n mailing list. The gnome-i18n team asked us to use iso-codes and we will not change this until there will be a shared consensus among the member of the i18n team to do so. Thanks, Paolo
Ok. I've already posted a letter to gnome-i18n. We will discuss the problem and try to get the consensus.
BooXteR, to me your argumentation leads to "don't use any external dependencies that include translated strings" which i think is not feasible. > And if I, as a coordinator of GNOME Belarusian l10n, get > bug-reports about wrong (btw automatically and weirdly generated) messages in > Gedit (and that's not "just a problem" because for now we have "belarusian" > translation of the message containing "Belarusian" that is widely considered by > Belarusian folks as obscure and abuse form) why don't you file a bug report against iso-codes then?
As you can see I specified that that would be enough to at least make sure that we have stats on Damned Lies and a (wiki?) webpage with info about the process of committing changes to the external sources. As I already told, I can't find the way to report a bug for iso_codes package though I tried hard enough. Any suggestions?
And that would be great if we have a Wikipage somewhere with info about external dependencies with messages that are shown in GNOME applications interface, with parts of interface specified. I think that will make the efforts of every l10n team a little bit easier.
iso-codes originates from Debian and is maintained by Debian contributors and developers, while obviously meant to be used *also* outside Debian. We probably need to improve the process of "external" (ie non Debian) bug reports for iso-codes but there are enough information to contact us in the README file of the tarball package we provide. The "official" contact address for iso-codes iso pkg-isocodes-devel@lists.alioth.debian.org. The translation of ISO_639 in Belarusian is very incomplete (1 translated string...added by Alastair, the originator of the iso-codes project, with "Belarouski" -phonetic transcription- for Belarusian) so any help maintaining it is very welcomed. PS: iso-codes l10n is also handled in the Translation Project. In general, I think it would be a really awful idea to fork iso-codes for GNOME purposes. If you guys need some scheduled releases to fit GNOME releases, we would deeply welcome suggestions and will be glad to do our best to release when it helps you
I would really like to see a proper web site for iso-codes, so that it's easier for people to contribute to it. It's a very important little project.
The iso-codes project has a web-page up on alioth, https://alioth.debian.org/projects/pkg-isocodes/ Suggestions on improvements welcome. I would think forking is a bad idea. Better to explain what you'd _like_ iso-codes to do: it exists to be used in projects like GNOME, after all... Syncing releases with Gnome releases for example, sounds reasonable. When thinking of releases, realize that iso-codes contains two things: (1) The ISO standard lists, in XML format. (2) The translations of the strings. We aim to release when (a) the standards change in some way, or (b) there are sufficient translation changes to justify it. We aim to keep the XML schema compatible. Hence, it is useful to update the lists when the standards change, even after a GNOME release: if a new currency is created, for example, data could arrive that GnuCash isn't able to handle, if it had an outdated version of ISO 4217. Hence updating the package is a good idea. On the other hand, doing a release in synchronicity with a GNOME / Debian release, with gnome-qa contributing to checking the quality, is a good idea, to improve the quality of GNOME.
Please, ow, please, provide me with an easy way to report a bug regarding this package! For now, I can't find the right way for doing this for almost two days... Is there a bugzilla or smth like that? Or should I send my translation files to the main -devel mailing list? I can't find easy to understand instructions regarding this topic. Can we make this process the GNOME-way (I mean easy enough even for non-geeks), without installing "reportbug" utility (on non-Debian system!)? Or maybe we can register a new component in main GNOME Bugzilla and make sure we CC one of maintainers of iso_codes when the component is explicitly chosen? That would at least create some kind of one-way communication line between GNOME and iso_codes. And I appreciate the idea of syncing GNOME and iso_codes release shedules.
I agree it should be easier to contribute to iso-codes -- or at least to find it. On the other hand, I'm totally against duplicating it. Where're not forking XULrunner, or GNU or whatever, why should we fork something specifically designed for reutilizaton?
> The iso-codes project has a web-page up on alioth, > https://alioth.debian.org/projects/pkg-isocodes/ > Suggestions on improvements welcome. Note that this is a more useful page: http://pkg-isocodes.alioth.debian.org/ That's the "Project Home Page" link, which not everyone will notice. You (and Debian, really) need a more obvious way to submit a bug. For instance, a "submit a iso-codes bug by clicking here" link, even if that's an email mailto. Don't force people to discover the correct project number and email format.
I will try to describe what a GNOME-i18n person needs iso_codes project pages to be: 1) A "big" link "Report bug" with a nice easy interface behind. 2) Better communication of iso_codes maintainers and its users - projects like GNOME or KDE. 3) Sync release shedules to make sure translators of such projects like GNOME can believe the next Ubuntu or Fedora or other distro contains full results of their work. It's not good when translator is messed with that "new" or "fuzzy" strings all the time. Rather stable release shedule gives translators the idea of their efforts sheduling. 3) Project pages should describe briefly the list of programs that use iso_codes. For GNOME: 1) GNOME Wiki should include info about main i18n external dependencies. 2) GNOME Damned Lies should at least show info about current state of iso_codes i18n. Ofcourse that way iso_codes page should contain enough info for non-geek to contribute his efforts into the project. I pray for usefullness of my notes. Thanks:)
Several notes: 1. We don't want to duplicate language names translation. Period. (even if damned-lies is guilty of the same wrongdoing) 2. damned-lies (on l10n.gnome.org) can easily show stats for iso_codes package (using svn://svn.debian.org/pkg-isocodes/trunk/iso-codes), and a link to a web page for it: what page should we link to? 3. we already have a lot of external translation dependencies, and we have lived with that for quite a while; while GNOME is very accessible to translators, we know that some other bits and pieces aren't (even including FreeDesktop stuff), but there is only so much we can do without duplicating translation effort. TranslationProject.org itself has gotten much better recently, so I suggest you use that to submit translations for iso_codes. Not sure how friendly is it to developers, though.
With my GTP spokesperson hat on, (In reply to comment #14) > I will try to describe what a GNOME-i18n person needs iso_codes project pages > to be: > 1) A "big" link "Report bug" with a nice easy interface behind. NOTGNOME ;) > 2) Better communication of iso_codes maintainers and its users - projects like > GNOME or KDE. I'd mark this as "better documentation for translators". Communication with upstream projects we depend on is generally good, and in best cases we ask them for nothing but regular releases :) > 3) Sync release shedules to make sure translators of such projects like GNOME > can believe the next Ubuntu or Fedora or other distro contains full results of > their work. It's not good when translator is messed with that "new" or "fuzzy" > strings all the time. Rather stable release shedule gives translators the idea > of their efforts sheduling. As far as changing strings, I'd say iso_codes package is pretty much bound to what ISO committees are doing. Frequent releases are indeed welcome to make translations more widely available, though. > 3) Project pages should describe briefly the list of programs that use > iso_codes. Again, lack of documentation on the GNOME side. GNOME Wiki is indeed a Wiki, so any help under live.gnome.org/TranslationProject is more than welcome. > For GNOME: > 1) GNOME Wiki should include info about main i18n external dependencies. They are up on http://l10n.gnome.org/releases/freedesktop.org Originally, I had them on "external" dependencies category inside core GNOME translation pages, but Claude moved them off to a separate "release". Of course, improving the documentation is always welcome, and GNOME grows only as far as you build it. If you know where is it lacking, just write it down :) Also, external dependencies are documented in the release notes of each GNOME release. > 2) GNOME Damned Lies should at least show info about current state of iso_codes > i18n. Ofcourse that way iso_codes page should contain enough info for non-geek > to contribute his efforts into the project. That's easily doable once someone collects all the information. That's basically why Damned Lies was designed to support showing external dependencies. We already list a bunch of them on http://l10n.gnome.org/releases/freedesktop.org but we can easily rename it to "external-dependencies" and add iso_codes to that (if I only knew it was available through public SVN, I probably would have added it ages ago). Someone can either add it, or report a bug against damned-lies. I think this bug should be closed as NOTABUG(but a feature), and discussion moved elsewhere.
I'll close this report. As noted above if there are issues with iso-codes upstream, they should be discussed elsewhere.