search

mrkara / gtranslator

A fork of the original 2-91 branch of Gtranslator from http://projects.gnome.org/gtranslator
GNU General Public License v3.0
1 stars 0 forks source link

[bgo#600387] "Replace all" removes the fuzzy status from all strings regardless #68

Open mrkara opened 7 years ago

mrkara commented 7 years ago

When using Search & replace, it changes the status of all fuzzy strings, even if they are not involved in the replacement. This is wrong, it may only change the status of those affected.

Originally reported by Jorge González at https://bugzilla.gnome.org/show_bug.cgi?id=600387

mrkara commented 7 years ago

This has just bitten me as well. This is a rather severe bug, marking it as such.

Renaming summary.

Steps to reproduce:

  1. Open a PO file with fuzzy strings
  2. Search -> Find and replace
  3. Enter some arbitrary Find and Replace strings.
  4. Hit "Replace all"

All fuzzies are marked translated

Originally posted by Christian Kirbach

mrkara commented 7 years ago

You are right. I'll try to fix it ASAP.

Originally posted by Ignacio Casal Quinteiro (nacho)

mrkara commented 7 years ago

What happened with this bug?

I'm using gTranslator compiled from master branch and this bug persists. Search and repalce is a very useful tool, but it is unusable if the po file has fuzzy strings.

Thanks :)

Originally posted by Daniel Mustieles

mrkara commented 7 years ago

Well, nacho does some work on gtranslator as I can see from the git commits, but apparently he has not had enough time or other priorities to work on this one.

I would be happy if he looked at this, too. Patches are always welcome :) At the moment I do not have enough spare time to look into this.

Originally posted by Christian Kirbach

mrkara commented 7 years ago

Bug 657069 has been marked as a duplicate of this bug.

Originally posted by Ignacio Casal Quinteiro (nacho)

mrkara commented 7 years ago

Well, the main problem here is that the search is probably the crappiest part of gtranslator. Maybe we can make a hack to fix this, but fixing it correctly which is the reason I didn't do it as it would require quite some rewrite needs a lot of time.

Hack: We must set a flag in the tab specifying that the tab is in search mode, this way when we change the message we keep the state.

Correct: Right now we keep 2 lists, the first point would be to fix this, where the TreeModel would implement an iterable interface and we would feed that interable list instead of having the treemodel and the GList. Once we have that ready things would become easier and we could think on easier fixes for replace and other problems derivated on this.

Originally posted by Ignacio Casal Quinteiro (nacho)