On 04/12/2017 07:55 PM, Ted Felix wrote:

>    One thing I noticed...  make-ts generates three files that are not in
> version control:

>    These are generated temporarily to make sure strings from various
> non-code places end up in the .ts files.  Since we don't ignore these in
> version control, they are a nuisance and have to be deleted manually or
> excluded when committing.

Why do they require special handling when committing?  They aren't under 
version control, so Subversion ignores them.

$ echo garbage > data/AutoloadStrings.cpp
$ svn commit data
$ cat data/AutoloadStrings.cpp
garbage

I admit they're a weird hack, but I haven't paid these files any mind in 
years.  I don't see this as a real problem.  Maybe it's a git thing?

> 1. Go ahead and commit them.  The advantage to this is that they are
> always available for translators to refer to, even if they don't run
> make-ts.  It also makes it clear that these are to be in version control.

What possible advantage is there to putting them under version control?

> 2. Add them to the svn:ignore property for the data directory.  This way
> they won't be accidentally committed.  Translators can generate them any
> time they want, and they won't show up when committing.  This is
> probably the most gentle change.

I don't see the harm, but translators never generate these files.  We 
generate them as an intermediate step between editing, eg., the .rc 
files and putting updated strings into the .ts files.

The only time translators look at code is when it's not clear what a 
string means in context.

> 3. Have the make-ts script delete them once it is done.  My problem with
> this is that the files will no longer exist if someone runs make-ts and
> starts doing translation work.  I assume that the translation tool will
> then have nowhere to point them to for an explanation as to why these
> strings are in the .ts file.

In of itself, that probably isn't such a big concern.  These files don't 
have any especially useful context information anyway.

>    Any preference for any of these solutions from the perspective of a
> translator?

Translator perspective:  Who cares?  Seriously, translators do not care 
in the slightest what happens with these files.

I don't care either, beyond not breaking anything.  If it ain't broke, 
what's there to fix?  That being said, if your OCD compels you to come 
up with a different way of handling these (which I could well 
understand, and am not mocking) then by all means do whatever you want 
with them as long as you don't break nothin'.

-- 
D. Michael McIntyre

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

Reply via email to