Question about DOC_LINGUAS variable
Hi all, I've noticed that nautilus-actions has changed the variable DOC_LINGUAS in the documentation's Makefile, so DL can't find the languages included on it. This is the declaration of the variable: DOC_LINGUAS = $(patsubst $(srcdir)/%,%,$(shell find $(srcdir) -mindepth 1 -maxdepth 1 -type d | $(GREP) -v $(srcdir)/C)) I guess it's ok to use to compile the documentation without worrying about if there is a missing language declared in this variable (indeed, it's a good idea), but if DL can't handle it, should it be changed to the traditional language list? I'm CC'ing Pierre, maintainer of the module. Thanks in advance ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Question about DOC_LINGUAS variable
Hi, Daniel Mustieles García wrote: > Hi all, > > I've noticed that nautilus-actions has changed the variable DOC_LINGUAS in > the documentation's Makefile, so DL can't find the languages included on it. > > This is the declaration of the variable: > > DOC_LINGUAS = $(patsubst $(srcdir)/%,%,$(shell find $(srcdir) -mindepth 1 > -maxdepth 1 -type d | $(GREP) -v $(srcdir)/C)) > > I guess it's ok to use to compile the documentation without worrying about > if there is a missing language declared in this variable (indeed, it's a > good idea), but if DL can't handle it, should it be changed to the > traditional language list? I know help.gnome.org (née library.gnome.org) won't handle it; I just checked damned-lies (stats/utils.py, get_doc_linguas) and I believe it will also fail on such a declaration. Fred ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Question about DOC_LINGUAS variable
Many thanks Fred for the info. I Pierre agrees, I'd like to fix it, as it should list all the languages available. Thanks! 2013/9/12 Frederic Peters > Hi, > > Daniel Mustieles García wrote: > > Hi all, > > > > I've noticed that nautilus-actions has changed the variable DOC_LINGUAS > in > > the documentation's Makefile, so DL can't find the languages included on > it. > > > > This is the declaration of the variable: > > > > DOC_LINGUAS = $(patsubst $(srcdir)/%,%,$(shell find $(srcdir) -mindepth 1 > > -maxdepth 1 -type d | $(GREP) -v $(srcdir)/C)) > > > > I guess it's ok to use to compile the documentation without worrying > about > > if there is a missing language declared in this variable (indeed, it's a > > good idea), but if DL can't handle it, should it be changed to the > > traditional language list? > > I know help.gnome.org (née library.gnome.org) won't handle it; I just > checked damned-lies (stats/utils.py, get_doc_linguas) and I believe it > will also fail on such a declaration. > > > > Fred > ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Question about DOC_LINGUAS variable
Hi, What about AS_ALL_LINGUAS as used in json-glib? https://git.gnome.org/browse/json-glib/tree/configure.ac https://git.gnome.org/browse/json-glib/tree/build/autotools/as-linguas.m4 -- Alexandre Franke ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Question about DOC_LINGUAS variable
It seems to be oriented to get the languages from the po/ folder, but I think it could be modified to get all the language folders in the docs one. Would it work doing something similar in the Makefile file or it's just for configure.ac files? 2013/9/12 Alexandre Franke > Hi, > > What about AS_ALL_LINGUAS as used in json-glib? > > https://git.gnome.org/browse/json-glib/tree/configure.ac > https://git.gnome.org/browse/json-glib/tree/build/autotools/as-linguas.m4 > > -- > Alexandre Franke > ___ > gnome-i18n mailing list > gnome-i18n@gnome.org > https://mail.gnome.org/mailman/listinfo/gnome-i18n > ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
gnome-maps translation
Hi, https://git.gnome.org/browse/gnome-maps/commit/?id=3b4531b6b911a33d6b7932d6c8def5f975046fd0 is broken because there is no po/as.po yet. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions to 'gnome-shell.master'
This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'gnome-shell.master': + "GNOME Shell (wayland compositor)" Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. http://git.gnome.org/browse/gnome-shell/log/?h=master ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Some translation review of strings in GNOME Software
Hi all, In the last few weeks we've been working hard on gnome-software so we can present it as a technical preview for GNOME 3.10. As it's a preview it's still in heavy development and ins't bound by the string freeze or future hard code freeze. So, as we can still modify source strings, I'm asking for some review of the new strings in gnome-software. Please let me know of any that are potentially difficult to translate, that need some more detailed translator comments to make sense or that need ngettext'ing to make sense for some regions. I'm open for ideas. Either send me an email, or grab me on irc [hughsie] tomorrow. Thanks. Richard. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gnome-maps translation
2013/9/12 Colin Walters : > Hi, > > https://git.gnome.org/browse/gnome-maps/commit/?id=3b4531b6b911a33d6b7932d6c8def5f975046fd0 > > is broken because there is no po/as.po yet. > Should be fixed by the next commit. https://git.gnome.org/browse/gnome-maps/commit/?id=8b310fbab8c29278c08370701284161f0d123dc2 -- Piotr Drąg http://raven.fedorapeople.org/ ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Question about DOC_LINGUAS variable
- Original Message - > Many thanks Fred for the info. > > I Pierre agrees, I'd like to fix it, as it should list all the > languages available. > > Thanks! > > > 2013/9/12 Frederic Peters < fpet...@gnome.org > > > > Hi, > > Daniel Mustieles García wrote: > > Hi all, > > > > I've noticed that nautilus-actions has changed the variable > > DOC_LINGUAS in > > the documentation's Makefile, so DL can't find the languages > > included on it. > > > > This is the declaration of the variable: > > > > DOC_LINGUAS = $(patsubst $(srcdir)/%,%,$(shell find $(srcdir) > > -mindepth 1 > > -maxdepth 1 -type d | $(GREP) -v $(srcdir)/C)) > > > > I guess it's ok to use to compile the documentation without > > worrying about > > if there is a missing language declared in this variable (indeed, > > it's a > > good idea), but if DL can't handle it, should it be changed to the > > traditional language list? > > I know help.gnome.org (née library.gnome.org ) won't handle it; I > just > checked damned-lies (stats/utils.py, get_doc_linguas) and I believe > it > will also fail on such a declaration. > > > > Fred > > > Many thanks Fred for the info. > > I Pierre agrees, I'd like to fix it, as it should list all the > languages > available. > > Thanks! > > > 2013/9/12 Frederic Peters > > > Hi, > > > > Daniel Mustieles García wrote: > > > Hi all, > > > > > > I've noticed that nautilus-actions has changed the variable > > > DOC_LINGUAS > > in > > > the documentation's Makefile, so DL can't find the languages > > > included on > > it. > > > > > > This is the declaration of the variable: > > > > > > DOC_LINGUAS = $(patsubst $(srcdir)/%,%,$(shell find $(srcdir) > > > -mindepth 1 > > > -maxdepth 1 -type d | $(GREP) -v $(srcdir)/C)) > > > > > > I guess it's ok to use to compile the documentation without > > > worrying > > about > > > if there is a missing language declared in this variable (indeed, > > > it's a > > > good idea), but if DL can't handle it, should it be changed to > > > the > > > traditional language list? > > > > I know help.gnome.org (née library.gnome.org) won't handle it; I > > just > > checked damned-lies (stats/utils.py, get_doc_linguas) and I believe > > it > > will also fail on such a declaration. > > > > > > > > Fred > > > Hi Fred and Daniel, Yes it was a try of optimization, in order to prevent me to worry about the exact list of languages. I was not conscious of the drawbacks in DL. Of course, I am OK to reverse this. Fred, if you are willing to fix it, you are more than welcome :). Thanks to you all for your valuable help. Regards Pierre ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Music: Freeze Break request
On Thursday, 12 September, 2013 05:26 AM, Javier Jardón wrote: On 11 September 2013 19:41, Matthias Clasen wrote: Given that gnome-music is still a preview in 3.10, and needs to grow these features, I am ok with it, as long as the translators are comfortable with the string additions. Agree here: 2/2 for release team On Wed, Sep 11, 2013 at 10:26 AM, Arnel A. Borja wrote: Hi, We know this is late, but we would like to merge more features to Music for this cycle, 3.10. Music is a preview release this cycle, and doesn't have much features, so we would like to add more to make it more usable. Because of that, we would like to request for UI and String Freeze Break for the following new features: * Notifications * Search * Playlists Also, a string freeze break is needed by this bug, which changes the accelerator for the application menu item "Now Playing" (clash with "New Playlist", they both use N as accelerator; "Now Playing" will now use P as accelerator): https://bugzilla.gnome.org/show_bug.cgi?id=707590 Notifications = This is the most tested of the three and was already approved for String Freeze Break. It is for showing the notifications at the message tray, also adds an icon there to control Music, and adds controls to the lock screen too so you could access Music without unlocking. We was not able to merge this before the freeze because of a libnotify bug blocking it. I added this here too because no one rejected nor accepted this feature for UI Freeze Break in the previous request. Search == This one is not yet implemented according to the mockups, it is just filtering for now in this cycle, but very convenient when searching for some songs, albums or artists on large music collections. This has been sitting for a long time now in a git branch, but wasn't completed until just recently because we were busy fixing bugs. As this is just filtering, it is not a huge change - we just added a search bar and wrapped the models with GtkTreeModelFilter. As far as I could remember, this won't add nor change any strings, so it only needs a UI Freeze Break. Playlists = This helps managing songs easier, so we would like to have this on this cycle too. It is now fully working except on removing songs on a playlist and needs some style fixes (borders, menu alignment, checkbox positioning, etc.) to fully follow the mockups. We have to move to totem-pl-parser from using grilo to parse playlists, that's why it wasn't completed before the freeze. Needs UI and String Freeze Break. Strings added: - "Playlists" (name of the view) - "%d Song", "%d Songs" (shows the number of songs when a playlist is selected) - "New Playlist", "Select Playlist", "Select" (in Add To Playlist dialog) - "_Play", "_Delete" (playlist menu) - "Remove from Playlist" (action button in Playlists view, selection mode, not yet added though) - We might add an additional message when no playlist is selected yet The branch for this feature has lots of commits, but they are actually smaller than they look, they are separated this way to make it easier to rebase. All three features and the bug report are approved and tested by the maintainers. We are providing packages for Fedora 19, openSUSE 12.3 and Arch Linux to let more people test these features (Music is backwards-compatible to 3.8 for this cycle, except that it needs the latest libnotify release), and the packages are in https://build.opensuse.org/project/show/home:arnelborja:gnome-music:git As for now, the Music team are the people who tested it, and probably users of our OBS repository. I use these features everyday since Music is my default music player (in Fedora 19 and openSUSE 12.3, using the packages from the OBS repository), and I haven't encountered any crashes. Screenshots for these features are in http://kyoushuu.wordpress.com/2013/09/11/gnome-music-notifications-search-and-playlists/ and the git branch is in https://git.gnome.org/browse/gnome-music/log/?h=freeze-break Regards, Arnel A. Borja ___ gnome-doc-list mailing list gnome-doc-l...@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-doc-list ___ gnome-doc-list mailing list gnome-doc-l...@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-doc-list Thank you Matthias Clasen and Javier Jardón! Merged the notifications and search branches to master. Still waiting for i18n team for second approval on playlists and the application menu bug. Regards, Arnel A. Borja ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Clocks late break request (geolocation)
Le mercredi 11 septembre 2013 à 20:29 +0200, Piotr Drąg a écrit : > 2013/9/11 Paolo Borelli : > > I know it is very late in the cycle, but I'd like to ask you if I can > > land support for geolocation in gnome-clocks. > > The feature was developed by Evgeny during GSOC and it is the natural > > companion to the geolocation support that was added to the control-center, > > so I think it would be great to have since geolocation support is one of the > > themes of 3.10 (maps, etc) > > > > The code has been reviewed and tested and I am confident about it, the delay > > in landing it is mostly due to getting all the moving parts aligned > > (geoclue2, vala etc) > > > > The UI impact of the feature is minimal (no new dialogs or buttons, simply > > the clock for the current location is added at startup) > > > > The impact on translations is one new string (the gsetting) > > > > 1/2 from i18n. 2/2 from i18n. Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
