[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Make conflict message translatable

From: Mattias Engdegård <mattiase_at_bredband.net>
Date: Wed, 3 Apr 2013 01:35:20 +0200

2 apr 2013 kl. 15.51 skrev Julian Foad:

> A quick update. I tried your patch and the test suite fails here:
>
> FAIL: upgrade_tests.py 24: wc with add-add and del-del tree conflicts
>
> That's failing in local_reason_str() with kind=none and
> reason=deleted, so at least we need that function to handle that case.

Quel blamage! I'm really sorry - I thought I had run all the tests,
but apparently not.
There is no excuse for that.

> This indicates that perhaps the only way to get kind=none is an
> upgrade from a previous WC format. We could handle such unusual
> cases by constructing a response from the separate parts, and not
> attempt to use different messages for every possible combination.
> The important thing is to use well written messages for the common
> cases. The unusual or impossible cases can just have some inelegant
> construction like we were doing before, and then we'd be sure to
> handle any case that might arise rather than throwing an error.

I agree. Here is a new patch which does exactly that. It re-uses the
XML strings for the unusual case since there really is no point in
translating them.

[[[
Make the conflict message "local %s %s, incoming %s %s upon %s"
translatable by constructing it from longer parts, each translated,
instead of single words (some of which were not translated at all).

* subversion/svn/cl-conflicts.c
   (svn_cl__get_human_readable_tree_conflict_description): Build
string out
    of translated sub-phrases rather than from single words.
   (local_reason_str, incoming_action_str, operation_str): New.
   (map_conflict_action_human, map_conflict_reason_human,
    action_str, reason_str): Removed.
]]]

Received on 2013-04-03 01:35:56 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.