On 03/16/2015 10:52 PM, Axel Dörfler wrote:
On 03/16/2015 07:48 PM, Andrew Lindesay wrote:I think it makes perfect sense to put the default pretty name into the package itself. For one, it's pretty much no work for the packager to add this information, and then, I think it makes sense to have that information available in the CLI tools, too.It would be good if you were to call this "title" as that is already through the HDS code -- although it could be re-factored. When you do implement this change, could you please provide me with a sample HPKR file that I can work from to implement the take-up of this in the application server. Do you have any idea of timing for this change?You make it sound as if I volunteered to do this change already :-) So far, I only stated my opinion -- once we've discussed this (if necessary), I guess I could make time to actually implement it for real, too. In any case, I would like to hear Oliver's and/or Ingo's opinion on this one, too.
There's a long-standing item on the package management TODO list under "Package/package repository format": "Add localization support." As I have already written on this list, the translations of title, summary, and description (copyright?) should be available either in the package itself or via the repository, so that pkgman can display them (and the solver search them!).
My plan for implementing it -- should I ever get to it -- is:* The package itself can contain the translations -- either as child attributes of the default (English) title, summary, description attribute or as top level language translation attributes with title, summary, description child attributes. This allows for self-contained packages which e.g. commercial vendors might prefer (instead of providing a repository).
* A repository, however, would provide a translation file per language containing (only) the translated items for each package. So the package manager can download (besides the repository index file) just the translation files for the preferred language(s).
* The translation process could work similarly to that for the Haiku main repository: The English translations would be in the recipes. Catalog key files would be generated by a periodic build process and uploaded to a translation server. Translations would be pushed periodically to the HaikuPorts repository. The repository building process (or a separate process) would aggregate the per-package translation files into translation files for the repository.
I figured that the existing translation infrastructure (Pootle) would be used, but I guess HDS would work as well or even better.
CU, Ingo [1] https://dev.haiku-os.org/wiki/PackageManagement/TODO
