To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=51121
------- Additional comments from [EMAIL PROTECTED] Wed Jun 29 07:21:58 -0700
2005 -------
>> This can easily be achieved by "touch desktop/share/content-sniffer" [..]
>
> I am not sure I am with you here: are you proposing to add a sample of each
> file type and sniff for the magic signature ?
No - "content-sniffer" would just be a file where the magic part could be read
from - basically what the openoffice.org.xml template contains...
>> This is on purpose, it is easier to parse, I don't need the hard-coded
>> translatin from impress to presentation, from math to formula, etc..
>
>Isn't this mapping more related to the fact that the mime-types are needed as
>anchor to know where to insert the translations but to parsing a merged
>documents.ulf ?
I don't understand that one. I read the components from documents ulf and read
the mime-type from the $component.desktop files.
You have a hardcoded mapping: mimetype from openoffice.org.xml -> component.
This mapping is hardcoded for every mimetype/component. So basically you list
both the mimetype as well as the sections twice.
(Mimetype in template and script, sections in document.ulf and script)
> Also: your script relies on internals of the translation process here: as long
> as you don't have a "contract" with the l10n framework maintainers, the
> structure of sdf files is subject to chance without notice.
It is very unlikely that this will change without notice. If it does, the
various lanugage-communities will rise (since they rely on the fileformat for
po-file creation), the way the help-index trees are created rely on the format
as well...
But it is a point. I think parsing localize.sdf is faster (but did not do
benchmarks..)
I read the german and english strings from documents.ulf already so changing
that to read everything from it should not be hard... But we have two different
approaches handling the "section spans multi-lines" problem. (I read the section
as a single record, you handle it with while...)
>a) make the shared-mime-info file the source for all mime-type handling (this
> will require some icon renaming) and
Why would this involve icon-renaming?
> c) copy the existing translation database to their new keys (will need help
> von Ivo & Ause for this)
? Don't understand that either. Why would you copy translations?
> However I am not sure if this should done for OOo 2.0.
What should be done for OOo 2.0 is: Only create the openoffice.org.xml once.
All other stuff ("centralize" the mime-stuff and have the legacy files generated
from that) is a bigger task for the following versions.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
