"Title" problem fixed in English templates

Use "Salutation" instead of "Title" for personal titles, for the benefit
of translations.

Removing NPL-specific links

Comment syntax fix to keep the translation tool quiet

-v option (undocumented) for more verbose output

Fixed bug in "create" action reported by Benedict

Bit a bit lenient on whether a file name has been set

Consistency fix

Fixed a bug which caused </script> to be not recognized as a tag

Spelling mistake

Oops, "Title" is untranslatable. Need to fix the English templates some time

Update including correction

From the old translation

Minor update

"Polish" should be capitalized

Missed this one. This need to have the meta tag too.

Interim update

Interim update

More bugs that prevented some strings from being translated properly.
This time it's a trimming bug.

This looks much better if the screen is smallish.

Off-by-one bug

Minor dialect correction

Bug that prevented msgid's with French characters from being translated
should now be really fixed.

Charset "translation" line

Missing charset declarations. Needed for translations generated by the
translation tools.

Oops, forgot to take out some debugging print statements

More interim updates

Comment syntax correction

Interim update

"maxlenght" should be "maxlength"

Fold all consecutive whitespaces into single blanks. This avoids problems
when minor whitespace changes occur in the original templates; it also
makes the strings much easier to read (e.g., instead of "foo\n\n\t\t  bar",
xgettext.pl will now always generate "foo bar" and tmpl_process3.pl will
understand it to be the same as the original string).

Preliminary support for "analysis" of strings with <a> tags.

Early termination of analysis if we encounter some strings, such as </h1>
or | or ||, in order to avoid extracting strings that are unnecessarily
long and which doesn't add any meaningful context.

Try to relax the criteria for allowing groups of tokens without TMPL_VAR
to be combined together into one string. This seems to have the desired
effect (that "<b>foo</b> bar" type strings are now recognized in one piece).

However, "<h1>foo</h1>\nexplanation"-type things may now also be (arguably
wrongly) recognized as one piece.

Grammatical correction

The French character handling fix for tmpl_process3 was not checked in
for some reason.

Try to remove trailing ( in strings too.

Ugly hack to get rid of the close tag in pathetic "foo %s</h1>"-like strings

Templates with French characters were not handled properly in the install
step. This is now fixed.

Some French letters were ?

Handle the iso8859-1 charset somewhat, so that when the po file is in
either iso8859-1 or utf8, msgmerge(1) won't crap out. The code is ugly;
the conversion table is hard-coded, and in some place not very appropriate.

However, this does fix the case where a few strings containing French
characters can't be translated. As a side effect, tmpl_process3 can now
also be used for French or other languages using iso8859-1.

Translation by way of ./tmpl_process & text_extract2.pl script

bugfix (wrong synch with rel_2_0)

Updates

Fixed bug where a <textarea...>#cdata</textarea> on one line won't be
scanned properly.

Minor updates

Minor update (after changing TmplTokenizer.pm)

Partially allow combination of several TEXT tokens. It seems that this
gives better strings. (Always allowing combinations gives havoc, we
currently avoid this by allowing combination only if the first and last
tokens are both TEXT.)

Updates

Minor capitalization correction

Preliminary checkin

Support %0.0s notation so that we can omit the %s as in Year%s for the
Chinese translation. (This won't work for all languages; ultimately the
English templates must be fixed.)

A few spelling and markup corrections
(Probably a bit unnecessary adding quotes in issues-top.inc)

Make the translation tool happier.

Try to not display like 40-line warnings too often

Escape ISO8859-1 characters. msgmerge still hates these strings, but at
least the po file merges.

Forgot to check for fuzzy-ness.

New scripts for translation into Chinese and other languages where English
word order is too different than the word order of the target language to
yield meaningful translations.

The new scripts use a different translation file format (namely standard
gettext-style PO files).

This seems to reasonably work (e.g., producing an empty en_GB translation
then installing seems to not corrupt the "translated" files), but it likely
will still contain some bugs. There is also little documentation, but try
to run perldoc on the .p[lm] files to see what's there. There are also some
spurious warnings (both from bugs in the new scripts and from buggy third-
party Locale::PO module).

New NPL templates

New NPL templates

Adding item information variable declarations to 'Waiting' section already present in 'Reserved' section

Warn against Apache #include directive

Updated w.r.t. the text-extract2.pl filter.

Adding variable declarations so that 'waiting' screen shows same information 'reserved' screen does, adding more address info

The previous change was wrong.

Allow trim to return the trimmed whitespace if the caller wants them.

Don't extract strings from the VALUE attributes of RADIO type INPUT fields;
these aren't translatable.

Insert the filename of the token into the TmplToken object too

Converted TmplTokenizer into a class. Everything still seems ok, but it is
not tested thoroughly.

Still more bugfixes for my own bugs.

$readahead is now an array @readahead which can contain TmplToken objects,
so "ungetting" tokens should not disturb the line number counter any more.

Fixed more bugs during the modularization

Further breaking up of the TmplTokenizer module.
A couple of minor fixes.

Avoid direct accessing of variables inside the module

Some functions should not be in the module; these are now removed.

Pulled the tokenizer out into a module. Hope this has been done right.

Minor factoring of construction of warning messages.

Don't bother warning about TMPL_VAR if the key is onclick, onblur, etc.
We don't know how to warn/what to suggest, & that will only confuse people

Fix spurious warnings if attribute is in the form foo="bar"</TMPL_IF>

Make a reasonable suggestion for ESCAPE= if we warn about lack of it

Fixed spurious warning about unescaped < inside cdata

Minor change to make the "closed start tag" warning more understandable

Don't complain about strange attribute syntax if what we see is a
reasonable templating control flow directive (if, else, unless).

Have to make it know what "closed start tag" notation is; other it spews
out more than a screenful or text for an "unknown token" when such notation
is seen

Fixed problem recognizing tags in the form of <foo ... bar=<!-- TMPL_VAR ... >>

Don't extract TMPL_VAR's as if they were translatable

Don't complain about </TMPL_IF> or </TMPL_LOOP> being strange attribute
syntax; they are fine.

The way TMPL_VAR is warned probably makes more sense now.

This should be still more correct regarding when to warn about TMPL_VAR
in attributes

More correct version of previous change

Make sure that if an attribute contains < or >, a warning is given; these
warnings aren't pedantic because (1) if it's a templating directive, it
might expand into something containing a real < and/or >, and (2) if it
contains >, the browser will close the current tag, and (3) if it contains
< and the browser knows what "SGML closed start tags" are (e.g., Mozilla),
the browser will also close the current tag.

Hmm. I didn't know there can be whitespace before and/or after = in
attributes...

Handle leading or trailing &nbsp;'s as leading or trailing spaces.
Make sure they are all trimmed off.

$re_end_entity is now used (by the above); there are &nbsp's (no ;)
in our templates.

Some needed HTML syntax corrections.

The fixed search.marc/search.tmpl (nothing between <textarea></textarea>)
caused an eof token to be incorrectly generated by next_token(). This
is now fixed.

Don't mindlessly spew out 40 lines of text in a warning message if we get
too confused.  Just say we are too confused.

This way of reporting line numbers should make more sense,
esp. for pathetic cases like search.marc/search.tmpl
(missing closing " for an attribute)

Display something useful if the user doesn't specify -f

Don't issue warnings for unquoted attributes containing [^-\.a-zA-Z0-9]
unless --pedantic-warnings is given. These don't seem to cause any trouble,
even in Mozilla's standards compliant mode.

Paul's problem #1 is now fixed: Bug in regular expression $re_directive.
Put my "grander plan" :-) in the comments

Don't extract purely-numeric strings like "1" either

Seems like I wasn't careful enough recognizing unknown tokens.  Incomplete
tags like "<b foo" at the end of the file seems to be discarded silently by
Mozilla, even in quirks mode. We now display a warning for these (in case
these ever come up by accident).

Minor wording rewrite in warning

Warn about unquoted attribute values containing [^-\.a-zA-Z0-9]