Koha-community/Koha
13
7
Fork 0
Code Issues Releases Wiki Activity
2213 commits 35 branches 612 tags 1.8 GiB
Commit graph

2213 commits

This branch
This branch
All branches
Author SHA1 Message Date
acli
12ce5c292f Minor updates 2004-02-20 07:25:38 +00:00
acli
3101a3b414 Minor update (after changing TmplTokenizer.pm) 2004-02-20 07:13:21 +00:00
acli
257b26d141 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.)
 2004-02-20 07:09:47 +00:00
acli
feb6e56449 Updates 2004-02-20 07:04:10 +00:00
acli
2102751d0d Minor capitalization correction 2004-02-20 06:16:28 +00:00
acli
96534eac9a Preliminary checkin 2004-02-20 04:38:36 +00:00
acli
b6c37e376e 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.)
 2004-02-20 04:38:02 +00:00
acli
e9f1656fc1 A few spelling and markup corrections 
(Probably a bit unnecessary adding quotes in issues-top.inc)
 2004-02-20 03:01:21 +00:00
acli
b7dd16f38d Make the translation tool happier. 2004-02-20 02:49:21 +00:00
acli
0d4f569ff3 Try to not display like 40-line warnings too often 2004-02-20 02:48:39 +00:00
acli
793f49ec7f Escape ISO8859-1 characters. msgmerge still hates these strings, but at 
least the po file merges.
 2004-02-20 00:39:26 +00:00
acli
14a62cc0c4 Forgot to check for fuzzy-ness. 2004-02-19 21:28:14 +00:00
acli
8b57901d85 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).
 2004-02-19 21:24:30 +00:00
oleonard
44b7d6ebc7 New NPL templates 2004-02-19 19:19:55 +00:00
oleonard
c69d8d42fb New NPL templates 2004-02-19 18:59:36 +00:00
oleonard
7a2a0fe018 Adding item information variable declarations to 'Waiting' section already present in 'Reserved' section 2004-02-18 16:51:20 +00:00
acli
053bb685ab Warn against Apache #include directive 2004-02-18 06:56:19 +00:00
acli
7be0c493d9 Updated w.r.t. the text-extract2.pl filter. 2004-02-18 06:39:34 +00:00
oleonard
84b3a7b984 Adding variable declarations so that 'waiting' screen shows same information 'reserved' screen does, adding more address info 2004-02-17 22:15:33 +00:00
acli
6e1a824374 The previous change was wrong. 2004-02-17 07:45:17 +00:00
acli
a9edbfe34c Allow trim to return the trimmed whitespace if the caller wants them. 2004-02-17 07:26:29 +00:00
acli
b318d2b8e3 Don't extract strings from the VALUE attributes of RADIO type INPUT fields; 
these aren't translatable.
 2004-02-17 06:30:38 +00:00
acli
4d2463c34a Insert the filename of the token into the TmplToken object too 2004-02-17 05:42:27 +00:00
acli
39dc31c2c9 Converted TmplTokenizer into a class. Everything still seems ok, but it is 
not tested thoroughly.
 2004-02-17 05:07:04 +00:00
acli
ae87eee049 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.
 2004-02-17 03:17:48 +00:00
acli
c1e51c54d5 Fixed more bugs during the modularization 2004-02-17 03:02:39 +00:00
acli
09c348bd9c Further breaking up of the TmplTokenizer module. 
A couple of minor fixes.
 2004-02-17 02:45:27 +00:00
acli
2f7192689a Avoid direct accessing of variables inside the module 2004-02-16 23:50:56 +00:00
acli
0b6030aecd Some functions should not be in the module; these are now removed. 2004-02-16 23:46:34 +00:00
acli
59d2e35180 Pulled the tokenizer out into a module. Hope this has been done right. 2004-02-16 23:42:57 +00:00
acli
de8d0930ee Minor factoring of construction of warning messages. 2004-02-16 22:50:34 +00:00
acli
2a9be2b2e6 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
 2004-02-14 09:50:11 +00:00
acli
1d45c47c02 Fix spurious warnings if attribute is in the form foo="bar"</TMPL_IF> 2004-02-14 09:41:28 +00:00
acli
f7b649f41b Make a reasonable suggestion for ESCAPE= if we warn about lack of it 2004-02-14 09:33:09 +00:00
acli
3fd0a52e0a Fixed spurious warning about unescaped < inside cdata 2004-02-14 09:23:34 +00:00
acli
050e1995d9 Minor change to make the "closed start tag" warning more understandable 2004-02-14 09:10:20 +00:00
acli
ce2189ef37 Don't complain about strange attribute syntax if what we see is a 
reasonable templating control flow directive (if, else, unless).
 2004-02-14 08:49:21 +00:00
acli
524a76f1b3 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
 2004-02-14 08:03:02 +00:00
acli
1b95b1698e Fixed problem recognizing tags in the form of <foo ... bar=<!-- TMPL_VAR ... >> 2004-02-14 07:49:37 +00:00
acli
2afa50bdda Don't extract TMPL_VAR's as if they were translatable 2004-02-14 07:13:09 +00:00
acli
10bec90dea 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.
 2004-02-14 07:07:36 +00:00
acli
0e2ff58b66 This should be still more correct regarding when to warn about TMPL_VAR 
in attributes
 2004-02-14 06:16:36 +00:00
acli
16992ec3f9 More correct version of previous change 2004-02-14 05:50:55 +00:00
acli
93740ec7ba 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.
 2004-02-14 05:46:38 +00:00
acli
a2f07d16f0 Hmm. I didn't know there can be whitespace before and/or after = in 
attributes...
 2004-02-14 05:35:04 +00:00
acli
a10bb7062a 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.
 2004-02-13 03:49:26 +00:00
acli
69589b31f1 Some needed HTML syntax corrections. 2004-02-13 02:46:02 +00:00
acli
b87b492773 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.
 2004-02-13 02:42:06 +00:00
acli
5af84e39db Don't mindlessly spew out 40 lines of text in a warning message if we get 
too confused.  Just say we are too confused.
 2004-02-13 01:48:58 +00:00
acli
412847fe93 This way of reporting line numbers should make more sense, 
esp. for pathetic cases like search.marc/search.tmpl
(missing closing " for an attribute)
 2004-02-13 01:27:03 +00:00