[haiku-depot-web] Re: Title "localization"
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-depot-web@xxxxxxxxxxxxx
- Date: Wed, 18 Mar 2015 11:09:02 +0100
On 03/17/2015 12:19 PM, Andrew Lindesay wrote:
My general approach so far has been to import English data from the HPKR
as "authoritative" and to allow non-English data to be augmented
manually into the application-server.
There is a challenge in that for any given package there may be many
different package-versions ("version + architecture") in multiple HPKG
files. These may be distributed with different summaries and
descriptions. Users are able to supply localizations which relate to a
package-version, but how to know when they are valid for a new
package-version with a possibly new summary and description? So far
this is done by observing the as-distributed summary and description
have not been altered and to carry forward the existing non-English
localizations in this case. Also when editing, the user has the option
to write their non-English localization to the latest package-version of
each distributed package version for each architecture of the package.
Sounds like a good approach.
In light of your comments, a different approach would be to store
manually entered localizations (summary, description and title) at the
package level (un-versioned) for any natural language and to allow those
to act as fall-backs when there was nothing supplied in the HPKR. The
application server could also then export that data in some way that, as
you suggest, could be used stand-alone or feed into the HPKG assembly
system. The only downside is that it would not be possible then to
store localized data in the application server for specific versions,
but if (as you have suggested) that material ends up in the HPKG at some
point anyway then this is probably a non-issue.
To clarify: While the package format and the package manager should
support that all translations can be stored in the HPKG itself, I think
this should only be done for standalone packages that aren't distributed
through a repository (e.g. for companies that want to provide a simple
file download). Any HPKG that ends up in a repository should only
contain the default -- English -- attributes. Translations would be
built into separate files (either one per language or one for all
languages). When building the repository, the translations for all
packages are then reorganized in per-language repository translation files.
So, as I see it, the requirements for HDS are:
For each registered package repository (assuming that in the future the
HaikuPorts repositories won't remain the only ones) the should be a
setting whether HDS is the authoritative source of translations. If it
is not -- this could be preferred by companies registering their
repository but wanting to do their translations in-house -- HDS should
import the package repository's translation files, but don't allow
editing them.
If it is the authoritative source of translations, the repository's
translation files should be ignored (or they could be imported once when
the repository is first registered) and the translations stored in the
application server should be used. The strings should consequently be
editable by users and there should be a mechanism to export translation
changes to the repository (translation file) building process.
For each version and architecture of a package there can be different
strings. When a new version of a package enters the system and the
English strings haven't changed, the translations from the previous
version should be copied automatically. Even if a string has changed,
there should be an easy way for a translator to create a translation
based on the previous version's translation.
While the strings for different architectures may differ, they probably
rarely will. So having the option to set a translation for all
architectures is certainly a good idea.
CU, Ingo
Other related posts:
