DTD files are using .properties comment style and break localization tools

RESOLVED FIXED

Status

()

Firefox
General
RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: Jeferson Hultmann, Assigned: Benjamin Smedberg)

Tracking

({fixed-aviary1.0})

1.0 Branch
fixed-aviary1.0
Points:
---
Bug Flags:
blocking-aviary1.0PR -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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:
(Reporter)

Updated

14 years ago
Version: unspecified → 1.0 Branch
(Reporter)

Updated

14 years ago
Flags: blocking-aviary1.0PR?
(Assignee)

Comment 1

14 years ago
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-
(Reporter)

Comment 2

14 years ago
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)
(Assignee)

Comment 3

14 years ago
Created attachment 156112 [details] [diff] [review]
wrap #preprocessor directives in SGML comments
(Assignee)

Updated

14 years ago
Attachment #156112 - Flags: approval-aviary?

Comment 4

14 years ago
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?
(Assignee)

Comment 5

14 years ago
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 ;)

Comment 6

14 years ago
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.
(Assignee)

Comment 9

14 years ago
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+
(Assignee)

Comment 12

14 years ago
Fixed on the branch.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED

Comment 13

14 years ago
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
(Reporter)

Comment 16

14 years ago
(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.