Re: building vanilla gnu.org-i18n

[Kaloian Doganov]

Yavor Doganov <address@hidden> writes:

    > Yes, let's go ahead.  When you copy the new templates, please commit
    > them even if they fail to build with the rest of the system.  We would
    > like to see what the errors are.

    That's self explanatory.  I'll only remove the sidebar stuff, as it's
    obsolete now.  

Thank you for doing this.  Now the repository is self contained, it is
easy to spot some issues:

1. When generating a pot-file, po4a-gettextize always updates the
  "POT-Creation-Date" field, even all other strings are identical.  For
  example:

--- gnu/po/rms-lisp.pot (revision 306)
+++ gnu/po/rms-lisp.pot (working copy)
@@ -7,7 +7,7 @@
 msgid ""
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
-"POT-Creation-Date: 2007-12-05 22:29+0200\n"
+"POT-Creation-Date: 2007-12-10 10:53+0200\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME <address@hidden>\n"
 "Language-Team: LANGUAGE <address@hidden>\n"

  I suppose we wouldn't want to commit such "changes" in www.  Thus we
  have to find a way to avoid commiting them, or avoid running
  po4a-gettextize on those cases.

2. Now Po4a's Xhtml module generates the same results for the templates
   (www/server directory) as the html module.  For all articles we
   already use the Xhtml module.  I suggest to switch entirely to Xhtml
   module.

>
    >     I plan to start working on the CVS commands -- it may be a bit
    >     premature but they're pretty important.
    > 
    > Could you please explain what is the desired behaviour of those SCM
    > (being CVS or SVN) commands?  I remember that we have discussed this
    > earlier, but I have no written record for it. :-/
>
    Newly generated files must be cvs add'ed automatically, otherwise the
    system would be much less usefull.
>
    As I see it, there will be a script invoked by a cronjob that would
    roughly do:
>
    1) cvs update of the whole repository
    2) invoke make
    3) cvs commit on success
>
    I dropped the idea of adding directories automatically -- this will be
    detrimental to the repository even due to a trivial bug.  The /po
    subdirs are not so many, so I'll add them manually when the time
    comes.
>
    More specifically, the system should cvs add these files if they are
    created by the make process:
>
    /prep/i18n/generic.xx.html (empty file)
    /path/article.pot (when web-translators managers add a new article)
    /path/article.xx.html (when a translator commits article.xx.po).
>
    >     I was thinking also about a way to generate meaningful CVS log
    >     entries, describing the changes.  Would that be useful?
    > 
    > It would be useful, I suppose.  I don't know who will read them when the
    > system is deployed and actually used, so I can not estimate the
    > importance of this feature.  But it is nice to have concsice log
    > messages instead of dummy ones.
>
    It would be useful, say, to quickly check which article.pot or
    article.xx.html corresponds to which version of article.html or
    article.xx.po.  I'm not sure.
>
    >     I think yes, but I might be over-estimating this.  I see that it
    >     won't be extremely hard to do it via the makefile.  Or it would be
    >     easier to use Scheme for this?  I don't know, please comment.
    > 
    > Honestly, currently I don't have and idea how implement this.  If you
    > can suggest a strategy for retrieving and composing the contents of the
    > log message, then we can think whether Make/Bash or Scheme fits the
    > strategy.
>
    I was thinking about this:  When a file is modified, an extra command
    will append the cvs log message from the original file.  Upon
    successful make && commit, this log file will be deleted.  In case of
    failure, it will not be deleted so that the accumulated messages will
    be used in the next run.
>
    >     Also, it would be nice to have a `report' target that would be
    >     language specific and will output the state of all files for a
    >     language team, and extended `full-report' that will check the
    >     activity of all teams for a certain period.
    > 
    > If you can define what these reports will contain, we can think about
    > how to generate them automatically.
>
    For language teams, a `msgfmt --statistics'-similar output would be
    sufficient, as a start (probably omiting files that are 100%
    complete).  We'll see, it's a bit early to think about this.
>
    >     Another idea is to implement a `check' target that would test the
    >     environment and all the tools we use.
    > 
    > This is a nice feature too.  Are there any relevant GNU standards or
    > good practices about how to implement such things?
>
    Autoconf or DejaGNU.  
>

-- 
Protect your digital freedom and privacy, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm