User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; pt-BR; rv:1.7) Gecko/20040809 Firefox/0.9.1+ Build Identifier: dtd files like bookmarks.dtd (see URL) are using .properties comment style (#). Once are malformed DTD, Mozilla Translator ignore them. Reproducible: Always Steps to Reproduce:
Can you give me a list of all the cases where this is so? I can go through the files and change them or add "outer" SGML comments as appropriate.
Assignee: firefox → bsmedberg
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
browser/locales/en-US/chrome/ browser/pageInfo.dtd browser/bookmarks/bookmarks.dtd browser/bookmarks/bookmarksProperties.dtd browser/cookieviewer/CookieViewer.dtd global/brand.dtd toolkit/locales/en-US/chrome/ global/console.dtd global/customizeCharset.dtd global/dialogOverlay.dtd mozapps/downloads/unknownContentType.dtd passwordmgr/passwordManager.dtd (aviary branch)
in http://bugzilla.mozilla.org/attachment.cgi?id=156112&action=diff#mozilla/toolkitoolkit/locales/en-US/chrome/global/customizeCharset.dtd_sec2 You completely deleted: # LOCALIZATION NOTE Character Encoding Preferences Dialog: Do NOT localize the term "Character Encoding" Does it mean, that this note is obsolete?
http://bugzilla.mozilla.org/attachment.cgi?id=156112&action=diff#mozilla/toolkitoolkit/locales/en-US/chrome/global/customizeCharset.dtd_sec2 > You completely deleted: > # LOCALIZATION NOTE Character Encoding Preferences Dialog: Do NOT localize the > term "Character Encoding" no I didn't, I just put it in an SGML comment... look up and to the right ;)
Sorry my fault, I was somehow irritated by the diff output.
bsmedberg: please could you change the license blocks to have the correct SGML comment style throughout - specifically, using the boilerplate from http://www.mozilla.org/MPL/boilerplate-1.1/? Having something different (e.g. a # prefix instead of a -) breaks my automated license parsing tools. If you are using a # prefix in order to get the preprocessor to remove these lines and cut down on size, then please consider using the BEGIN LICENSE BLOCK and END LICENSE BLOCK headers to recognise and trim the license instead - that's what they are there for :-) Moreover, you can keep licensing information in the file by retaining the "Version:" line. So a full license block can be collapsed easily and automatically to: <!-- ***** BEGIN LICENSE BLOCK ***** - Version: MPL 1.1/GPL 2.0/LGPL 2.1 - ***** END LICENSE BLOCK ***** --> Gerv
As I suggested recently in l10n newsgroup, I think it would be a good idea to "standarize" a way so localization notes are associated to the proper key(s). I'll paste the relevant part: "I suggest something like a .remark suffix to the key, in the same way as .accesskey, for instance, that can be associated to the key. And I'm not sure, but not including these keys in the resulting localized file, shouldn't break anything. Also, but this is minor, the starting comment in most (all?) of the files containing the license. Maybe a kind of "standarized" hidden style (like starting the key with "_" or another convention) so for instance, the _license key contains the license applied to the file." In fact, i think it should be implemented a general system so developers can include notes in a way that localizers can see them with MT or other high-level translation tool.
gerv, I don't have time to make a more complicated patch, but I welcome patches from you or from other localizers. Any alternative needs to 1) not include the entire license in the output file 2) work with MT (SGML parser) in source form 3) work with the preprocessor for build automation Oscar, we do have a standard for comments, it's the standard SGML comment syntax <!-- -->, and Henrik and others have discussed the possibility of getting MT6 to display these comments in the MT UI.
(In reply to comment #9) > Oscar, we do have a standard for comments, it's the standard SGML comment > syntax <!-- -->, and Henrik and others have discussed the possibility of > getting MT6 to display these comments in the MT UI. Well, I don't know at this time Henryk's opinion, and I might be wrong, but I'm afraid that doesn't cover my suggestion, since it seems that syntax cannot be associated to a specific entry, as for instance accesskeys are. The target is to not unlink useful developer notes for localizers, which actually are unlinked and lost.
Comment on attachment 156112 [details] [diff] [review] wrap #preprocessor directives in SGML comments a=shaver
Attachment #156112 - Flags: approval-aviary? → approval-aviary+
Fixed on the branch.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
I am about to check in the de-DE locale and thought, wow, you gotta fix this one, too, probably. Then I found out that our localisations in CVS don't have license plates at all, is that a good thing?
No, but it was the fastest way for me to begin with the translation. Now that the files in CVS are wellformed I'll update my Languagepack to include the licence and other comments.
You'd better :-) Stripping off licenses from derivative works is never a good thing, no matter how "helpful" it may be. Gerv
(In reply to comment #15) > You'd better :-) Stripping off licenses from derivative works is never a good > thing, no matter how "helpful" it may be. > gerv: Mozilla Translator removes all the comments from en-US files (it builds totally new ab-CD files). However, MT allows translators to add a global license string. Would you like to see license plates in ab-CD files?
Jeferson: that's probably not legal, strictly. The people listed as Contributors in the original licensing comments need to have their attribution preserved in derivative works (which translated files are.) The right thing would be to fix MT to leave the license block alone. Gerv
You need to log in before you can comment on or make changes to this bug.