[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
'Translations status' script generates files in repository
From: |
markdblackwell |
Subject: |
'Translations status' script generates files in repository |
Date: |
Thu, 27 Aug 2015 17:15:17 -0700 (MST) |
The script:
scripts/auxiliar/translations-status.py
contains a comment:
"USAGE:
cd Documentation && translations-status.py
Write:
translations.itexi
<LANG>/translations.itexi
out/translations-status.txt
Update word counts in:
contributor/doc-translation-list.itexi"
Only one of the files mentioned above is absent from the repository:
Documentation/out/translations-status.txt
The above script seems to update numbers in this repository file:
Documentation/contributor/doc-translation-list.itexi
Should this file perhaps be removed from the repository? and, instead,
should the script:
* Totally regenerate that file (outside the repository)? or
* Read a template file (in the repository), and write some other file (not
in the repository)?
Also, each of the following files contains the text:
"This file was generated by translation-status.py -- DO NOT EDIT!"
$ find * -name 'translations.itexi' | sort
Documentation/ca/translations.itexi
Documentation/cs/translations.itexi
Documentation/de/translations.itexi
Documentation/es/translations.itexi
Documentation/fr/translations.itexi
Documentation/hu/translations.itexi
Documentation/it/translations.itexi
Documentation/ja/translations.itexi
Documentation/nl/translations.itexi
Documentation/translations.itexi
Documentation/zh/translations.itexi
If these files are generated, then why are they in the repository?
Each contains a comment:
"Translation of GIT committish: 0"
If generating the manuals need these files, then, arguably, we can
regenerate these files while building the documentation. I suppose that way
would be less error-prone, for several reasons:
* No one need remember about, and coordinate, generating them at the right
times, explicitly.
* No one will be bothered by Git merge conflicts in these generated files.
* No one will be routinely ignoring merge conflicts on these files.
* No one will be tempted to edit the files.
* No one will need to determine whether their merge conflicts are solely in
(these) generated files and can be ignored.
This discussion might be relevant:
http://lilypond.1069038.n5.nabble.com/Conflicts-conflicts-everywhere-tp119342p119344.html
Are these files in the repository solely to keep a record of their changes?
Obviously, by using Git locally, we can check out the repository from any
given commit in the past. And using the above script, we then can regenerate
the files. Given this fact, why should the repository contain them? It may
be that:
* Generating these files requires building LilyPond first; and
* We don't require all documentation workers to build LilyPond.
In that case, can we instead keep a tarball of these files (from each
release) somewhere on a server, and not in the repository? IMO that would be
better, for all the above reasons.
--
View this message in context:
http://lilypond.1069038.n5.nabble.com/Translations-status-script-generates-files-in-repository-tp180292.html
Sent from the Dev mailing list archive at Nabble.com.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- 'Translations status' script generates files in repository,
markdblackwell <=