Clarifying the development process/what to do with fixes that require a string change

["Thomas Mills Hinkle" <tmhinkle gmail com>]

In GNOME Sudoku, I recently realized that users entering custom games can enter invalid games -- the program won't warn them that their game is invalid (and it will, in fact, register a high degree of difficulty for the game, since any game without a unique solution will require a lot of trial-and-error to solve). I wrote some code to warn the user if they enter an invalid game -- this seems like the minimal solution; it's unclear whether it would be good to allow users to play broken games or not (sometimes people publish broken games, so if someone wanted to enter it into the machine to solve, they might find it useful).

At any rate, any solution I can think of requires a new string to tell the user the game is broken -- and as I understand it, we're past the string freeze, yes?

I'm still new to the GNOME development cycle and I wanted to make sure I understood it right. I didn't want to commit a fix to svn that breaks the rules, but I also didn't want to risk forgetting about the fix during the next cycle. So is the idea that I wait until the 
2.19 cycle to introduce my fix? If
so, should I create a bug and attach a patch with the fix to the bug so
we don't forget about it?

Thanks,
Tom