Posted by joachim on November 9, 2009 at 5:19pm
| Project: | Localization server |
| Version: | 6.x-3.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
Just noticed that some of the strings are 5.x.
Could it be made possible to filter by core version, so we can focus efforts on 6?
Comments
#1
You mean focus on translating projects generally without picking a project filter but limit to releases which are 6.x?
#2
Oh I see there's a release box once I pick a project. DOH!
I guess I'm not sure what the workflow is.
If you just wade into the big mass of strings and start translating, then a filter for core version on everything might be useful.
If the idea is that you start with core, then pick popular modules, then it's fine as it is.
Feel free to mark this wontfix :)
I just have my beta testing hat on so am filing for stuff I find confusing.
#3
Yes, it is good you submit stuff you found confusing, it helps us make the initial experience even better :). I think the workflow totally depends on the team or maybe even the individual. The Hungarian team I know does virtual "sprints" of translations, and try to rally to get to a complete translation of a certain module (release). Other teams might go on looking for a specific string and translate that in whatever modules it appears to keep it consistent. The former is probably more common.
#4
Retitled to be more precise.
#5
Just marked #724526: Possibility to filter on Drupal version duplicate of this issue.
#6
#7
@tobiasb: this software is used beyond drupal.org (for translating gallery 2, musecore and possibly other open source projects). The cooler our module gets, the more other uses it will have IMHO, so we should strive to keep being as agnostic as possible in terms of what do we support.
We could either break these custom drupal specific things into their own modules (even export options come into mind), or need to figure out ways to do it without hard-wiring Drupal specifics (such as list of versions in this case).
Also, LIKE-ing on a text field could be very slow with this many releases we have.
#8
Subscribing. This way we could focus on keeping D7 module translations updated.
#9
Added #1118430: Set up the filtering/display setting UI for future growth to set us up for filter extensions like this.
#10
We desperately need this filter, so I installed a l10n_server sandbox to work on.
It would be possible to add a coreversion column in {l10n_community_release} to bypass the LIKE-ing problem, this would require a shema update, any objection ?
#11
Well the l10n_server attempts to be general purpose solution for translations, so at least make that a "major version number", not a "core version" thing. Adding yet another table with information on that might be helpful for speed. Would be good to verify whether the LIKE is actually slow on a database of the size of l.d.o.
#12
I would add a column instead of adding a table, a JOIN would be less efficient.
Is there a way I can do benchmarks ? Can I get a dump of the {l10n_community_*} tables ?
#13
You can ask my former summer of code student (http://drupal.org/user/109248), he should be able to provide you with a useful dump.
#14
No response from your student yet, could you give me this dump?