Re: [mantisbt-dev] "unable to reproduce"

[Victor B. <vb...@gm...>]

Hi Kristis,

I am assuming that you are comparing the string you parse to the enum
value in the $g_ configuration variable, i.e. the non-translated
version of the string.  If that is the case, then we can change the
resolution enums to not have spaces and leave the spaces only in the
$s_ localizations of these enums.  This will have no effect on
existing installations and should solve your problem.

Does this make sense?  Other developers, please correct me if you can
think of an issue in doing this change.

It is not recommended to have spaces in enum $g_ variables any way.
For example, in case of custom statuses, such names in the $g_
variables are used to construct PHP variables, and hence having spaces
in them will not work.  Hence, we use underscores and spaces only in
the localized versions.

The enums that have spaces in them are very old and I agree that we
should change them.  These are:

$g_reproducibility_enum_string
$g_resolution_enum_string
$g_projection_enum_string
$g_eta_enum_string
$g_custom_field_type_enum_string

We should ideally also avoid special characters like '<' and '-' which
are included in eta enum.

On 9/17/07, Kristis Makris <mk...@mk...> wrote:
> Hi Mantis gents,
>
> Just a heads up that resolution states like "unable to reproduce" become
> difficult to parse (because of the upredictable whitespace) if one
> wanted to implement automatic status resolution in integration of SCM
> with issue-tracking (like Scmbug does). Perhaps "unable_to_reproduce"
> would be acceptable ?
>
> e.g. parsing something like:
>
> status 547: resolved unable to reproduce
> status 548: resolved duplicate 547
> status 547: assigned kristis
> status 547: reopened
>
> is bound to cause problems. Solvable problems, but still usability
> problems. Users could be trained to instead write:
>
> status 547: resolved unable_to_reproduce
>
> and Scmbug could be replacing all "_"s with " "s, but some users will
> forget, and will have their commit messages refused, and will have to
> try again.
>
> Thanks,
> Kristis
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>