Re: Ubuntu Software Store: What it does, and how you can help
My vote is for "Software Center". Pros and cons: + "Software" is more general in meaning (more than just apps) and it seems to be the the most used term and already the term chosen at https://wiki.ubuntu.com/SoftwareStore. + Some lawers could also claim that "AppCenter" is too close to Apple's "AppStore" and thus infridge on their trademark. + "Center" indicates the place of control and tells the user that "this is the place to do your software operations". I think this is exactly what the tools is about. + "Center" and does not hint that the user needs to buy the stuff like "Store" does. However, "Center" can also include items that require payment, since Center has a broad meaning. + "Center" is easy to translate. At least I can't think of any translation to "Store" in Finnish that could also mean "Warehouse". Also most of the world population who do not speak English as their primary langauge associate "Store" with a shop and not as a place where something is stored. If you want to rename something into store, then rename repositories into stores. - "Center" should be "Centre" in UK English, but I think this is such a small issue that you shouldn't bother. If some user is really annoyed by this, he/she can always switch to the UK English translated interface. -- | Otto Kekäläinen | http://www.sange.fi/ -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Advice needed - moving GNOME help files into langpacks
Shaun McCance [2009-08-30 10:34 -0500]: > OK. I'm not a packaging expert, so I'll just have to trust > you on this one. But I don't see how splitting a package > into subpackages is any different than what gets done now > with -dev packages. If a file moves from e. g. libfoo1 to libfoo-dev, then you have the very same file conflict situation. In that case you have to declare a Conflicts:/Replaces: field to tell the package manager that libfoo-dev has a file which was previously shipped in libfoo1. But using that approach for langpacks would mean that language-pack-* had to grow a Replaces: field to _all_ packages it has files for, i. e. to perhaps 50 or 100 GNOME packages. This might have a serious impact on the package manager. > So, with your proposed solution, in Yelp 3 you would need > to patch Yelp to also look for help files there. If you > were to use a directory structure like > > /usr/share/langpack/gnome/help/empathy/de/ > > Then you'd just need to ensure that /usr/share/langpack > is in XDG_DATA_DIRS (or modify Yelp to auto-insert it, > which would be a much smaller patch). That sounds great, and indeed much more elegant and robust than the symlink-mania. Good to know that it will only be an intermediate crutch. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Ubuntu Software Store: What it does, and how you can help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Loïc Martin wrote on 28/08/09 12:20: >... > We all seem to be copying the App Store from Apple (nothing wrong with > that), but perhaps the part we should change isn't so much the first > part in "App Store", but the second one? After all, both provide the > same goods (Apps), while we'll be trying to differentiate on the > experience (Store vs a different word). >... In the short term, version 2.0 of the Store will provide thousands of software packages that are not applications, such as fonts, themes, codecs, and screen savers. In the long term, I am pretty sure that in twenty years, "software" will still exist and be publicly relevant. I am much less certain that "applications" will. Cheers - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqahXgACgkQ6PUxNfU6ecqYyACfRXXeNJ7SE6dVP/Zlp/0oBVMQ 3jkAniCAiq1kFgCq8XfrQ89xduUK6i2u =gkna -END PGP SIGNATURE- -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Advice needed - moving GNOME help files into langpacks
Hello again, > to get yelp to pick up the omf files in that location, I'm > pretty certain you only need to modify rarian Argh, while this seems true for most programs, it already breaks with gnome-terminal. That unfortunately doesn't just call ghelp:gnome-terminal (as most other GNOME programs do), but terminal_util_show_help() detects the locale and assembles the xml file path all by itself. I. e. with my rarian patch and moved files, "yelp ghelp:gnome-terminal" works fine, but pressing F1 in g-t just gives me the C help. Now, if it were _only_ gnome-terminal, this could be fixed to just throw away this redundant code, but at this point I'm not sure how many other packages would break with that. So perhaps it's better to use the symlink farm. There will be many of them, one for each file (since dpkg wreaks havoc with symlinks to directories), but I tested that dangling symlinks are handled gracefully. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Advice needed - moving GNOME help files into langpacks
Hello Matthew, hello Shaun, Matthew East [2009-08-27 23:19 +0100]: > I've had a chat this evening with Shaun Mccance, the Gnome yelp > maintainer. It seems that yelp gets its paths from rarian, and rarian > gets its paths from the content of the omf files. So we can patch the > omf files (seems to me to be a big job), patch rarian, or use the > symlink idea of Loïc. > > I've pasted the conversation here and hope that it helps! I'm afraid I > was asking rather uninformed questions, as I don't have a good > understanding either of how yelp works, or of how Ubuntu packaging > works. But hopefully it takes things forward a little. > > http://pastebin.ubuntu.com/260590/ Thanks for this conversation! To clarify why we need this dance in the first place: Martin can't put these files in /usr/share/gnome/help because that will break upgrades because it seemed straightforward enough to me to just drop the extra files in the right place One assumption from dpkg (and most probably rpm as well) is that a particular file can only be shipped in one package (at a time). Thus if you have a file /usr/share/gnome/help/foo/foo.xml, which is currently shipped by foo, and then you install a language pack which also ships that file, the package installation will fail. We can enforce that foo is upgraded before the language pack installation, or that the langpack will overwrite files from foo, but that would require said list of 50ish "Replaces:" declarations. This isn't just a transitional problem either: people can install third-party .debs, or locally built packages which include the help files at the original place, and they would again be uninstallable due to file conflicts. Now, patching the omf files isn't much work at all, it can happen automatically during package build in pkgstriptranslations: while removing the gnome help files, it could also apply some seddery to the omf files to change /help/ to /help-langpacks/. However, we'd still have the same file conflict problem with the omf files themselves. now, that won't work for mallard documents which basically means empathy Shaun, what do you mean here? The current empathy in Karmic (2.27.5) seems to use the standard gnome help/omf system. So it seems to me that the langpacks should ship the help files in /usr/share/gnome/help-langpack/ and the omf files in /usr/share/omf-langpack/, with the paths mangled accordingly (*/help/* → */help-langpack/*). Then a two-line rarian patch would fall back to /usr/share/omf-langpack/ if the requested file does not exist in /usr/share/omf/. With that order, locally installed files always get preference, which is what we want. With that we avoid a symlink tree which would clutter packages and potentially cause bugs and problems with dangling symlinks, and we retain the possibility of changing the implementation easily, since we just have one tiny central patch in rarian. I have the rarian patch ready now, and first experiments work very well. Thanks for all your input! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
