Currently, adding locale information for a language involves rebuilding libreoffice. This bug would enable such information to be supplied via an extension. It involves two parts: 1. Add registry information under Linguistic/ServiceManager to specify the location of a locale information file. 2. Produce a binary? format and parser for libo locale information. Or should we just read the XML? Binary would be quicker, XML would be simpler for users.
@Eike, Do you think this enhancement is feasible/makes sense or should we just be realistic and close it as WONT FIX?
@Xisco - in the old days the philosophy was, if it's a valid request (i.e., not totally absurd) we would just mark as NEW and let the reporter know that enhancements are done by volunteers almost entirely, the vast majority of enhancements are never implemented, but, maybe a developer will at some point find this interesting enough to do. Has that "policy" (maybe philosophy) changed? Letting it rot in UNCONFIRMED land isn't helping anyone.
This is a good solution. Better than rejecting it with won't fix, because of priority concerns. Issues are raised for all kinds of reasons. Some as ways of having a discussion with volunteers on the best way to do something - hint hint :)
(In reply to martin_hosken from comment #0) > This bug would enable such information to be supplied via an > extension. It involves two parts: > > 1. Add registry information under Linguistic/ServiceManager to specify the > location of a locale information file. > > 2. Produce a binary? format and parser for libo locale information. Or > should we just read the XML? > > Binary would be quicker, XML would be simpler for users. Note that .oxt extensions are meant to stay compatible with future LO versions as much as possible. That has implications here, for both the point where such locale information is hooked into LO (i.e., a configuration property in the registry) as well as the locale information file format.
(In reply to Stephan Bergmann from comment #4) > (In reply to martin_hosken from comment #0) > > This bug would enable such information to be supplied via an > > extension. It involves two parts: > > > > 1. Add registry information under Linguistic/ServiceManager to specify the > > location of a locale information file. > > > > 2. Produce a binary? format and parser for libo locale information. Or > > should we just read the XML? > > > > Binary would be quicker, XML would be simpler for users. > > Note that .oxt extensions are meant to stay compatible with future LO > versions as much as possible. That has implications here, for both the > point where such locale information is hooked into LO (i.e., a configuration > property in the registry) as well as the locale information file format. I guess then it's simpler to rebuild LibreOffice than keeping the extensions compatible across versions. Closing a RESOLVED WONTFIX