Closed Bug 425521 Opened 18 years ago Closed 18 years ago

Do not attempt to translate if language is english

Categories

(support.mozilla.org :: Knowledge Base Software, task)

Product:
support.mozilla.org
Component:
Knowledge Base Software
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: nkoth, Assigned: nkoth)

References

Details

No point trying to translate if language is english. It just slows things down.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
What exactly changed? I don't understand the report.
The code was checking the database to translate the English strings in the source into English. Now it doesn't.
Are we then losing the ability to "translate" strings like "edit this page" to "Edit this article" from the interactive translation UI, meaning we have to update the template instead (and thus losing the localizations made on the previous strings)? Or are we talking about other types of strings here?
yes. this is what we are losing.
After Bug 395271 – Land Memcache fixes, is fixed, we can explore reimplementing that ability using memcached cache.
I don't think the en-US "translation" is needed, but we really should do a UI strings review and make sure we have exactly the strings we want to have before we ask people to localize them. With the current implementation, even a small change from "edit this page" to "Edit this page" will break all localizations for the original string, which is not ideal. Maybe when we change the strings in the template, we could also run a db query to update the strings in the db so we don't lose the connection between the en-US string and the localizations? Obviously that would only make sense if the change is subtle.
correct. see bug 425713.
When you resolve bugs, please put the revision # into a comment and mark keyword push-needed. Thanks!
fixed in r11675
Keywords: push-needed
Keywords: push-needed
Was just pushed (yay!)
Whiteboard: tiki_triage
Whiteboard: tiki_triage → tiki_discuss
Not sure why tiki_discuss was added here.
I am wondering how this fits in with the i18n sync issues with a global plan https://bugzilla.mozilla.org/show_bug.cgi?id=539157 What does everyone think?
Here is an example of overriding English is useful: https://bugzilla.mozilla.org/show_bug.cgi?id=536128
Once we move to gettext, I think the original pain point here (performance of checking for en-US localizations, which wasn't even quantified/profiled in comment 0, so I don't know how bad it was) will be gone. While we might not need to have en-US localizations for everything, it's so easy in gettext (and avoids the problem in comment 3) that there'll be no reason not to. tl;dr version: After we move to gettext, I expect we'll essentially revert this.
Whiteboard: tiki_discuss
You need to log in before you can comment on or make changes to this bug.