-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not save summaries in the database #343
Comments
This seems very reasonable, might be the time for it as well. |
|
@fjarrett Do we have green light for this? Here's my plan for this one:
|
All summaries are essentially composed of meta values, so we're safe on that front. I think we should have some kind of fallback, since not all sites would need this change, and since this change will essentially bring some more processing requirements on multiple ends. |
Right, because there are additional |
We'll need to grab ALL metadata, so actually two queries has to be executed, one for the record(s) and one for meta record(s) as well. |
Just a few questions about how this would impact other things:
|
For all of that, i do think we should make the language switching stuff opt-in by users, so all things are stored in English, and they're only processed in real-time if the user has switched the option on. |
@fjarrett @shadyvb Storing summaries in English is not the greatest solution here as well. One the main advantages of this idea is being consistent. We should be able to change any summary text on development. To satisfy all those points, I think the best idea would be to save summaries in separate table, with language code. That would make records fully searchable in any available language case. We'd then need smart updater to change saved summaries when needed. Anyway, I would use summaries field only on search engine and display results dynamically. |
Wait, are summaries currently being stored in English or are they being stored in the current If they do want to switch I realize this has implications for multisite, though, as each site could have a different |
@powelski did explain some use cases where the current implementation, or any regenerate-whole-data-on-demand solution, would simply create an inconsistent experience with data in multiple languages. And i can vouch for those use cases being a non-native English speaker myself. And yes summaries are stored in the current WPLANG, but what i was proposing my last comment was to actually store them in English, disregarding the current value for WPLANG, only as a fallback if users doesn't opt-in for language-specific summaries. Update: Not necessarily English, might be whatever language they have, on condition that this be the only language used ( if no users opt-in for the real-time generation of translated summaries ). |
@westonruter Yes, it would be bad 😄 Imagine you have part of your logs in Polish. |
@powelski @westonruter @shadyvb
New summaries and changes to existing summaries are becoming more and more rare. Of course this happened a lot during these first few months because we were maturing the plugin and adding a lot of new things, but this is going to be happening less and less now, so the notion that translations for summaries have to be updated after every release is not exactly the case.
So an alternative solution to this problem would be to offer an option to just reprocess the summaries when translations are updated so all past entries are updated appropriately. Or if a language pack suddenly becomes available that matches your |
Just to piggy-back on my alternative solution above, if we build a more robust API for handling DB update routines (as suggested in #379) then we can reprocess summaries with ease when language packs are added/updated that match the site's We could even have a separate routine just for language pack updates, with it's own custom message: "Aktualizacje dla danego języka (pl_PL) są dostępne, niech przerabiają bazy danych." 😄 |
@fjarrett You speak Polish and you didn't tell me! 😿 What I'd really love to have here is also being able to translate Stream on multi-lingual backends. That could be done with the builder as well, of course, but each language would need to be built separately with language code attached. |
@fjarrett @powelski Another important usage case to consider is multisite. I currently have my multisite configured with the Network Administration in English, and some sites in Italian. Currently, in #154 the Network Admin Stream displays summaries in whichever language they were stored in - so if Stream had an Italian translation then some entries would be in Italian and some would be in English. Ideally, the Network Admin should be able to view all summaries in whichever language they choose, regardless of the language used by the sites. |
What about this:
The caveat about this is that a theme could have multiple localizations for a widget's name and a sidebar's name, but the localized strings wouldn't be used here in the summaries, since the stored template vars would be whatever language was active at the time that the entries were stored. If you tried storing the widget ID (base) and the sidebar ID instead, and looked up the localized strings on the fly when listing the records, then this seems like it would then break the ability to search. |
@westonruter This seems like a good solution to me. I see a few issues. I think it's acceptable to store things like However, I don't think we should be searching keys like The primary problem here is that this solution assumes a base language of English. Let's assume that my network admin interface is in French and the database summary is Further, foreign search terms could return unrelated results if they match an English word that has a different meaning. e.g. gift (German for poison) would match gift (English for present). Fine means 'slim' in French. Will is the German word for 'want'. Attend in French means 'wait'. Share in French means 'flesh'. This is why the summaries should be primarily generated, not stored. Here's another alternative: store template variables as a JSON array in the database (but not associative), and have connector classes generate the summaries. _connectors/widgets.php_ $summary_data = $record->summary_data;// array( 'Hello World', 'Text', 'Primary Sidebar' );
$summary = sprintf(
_x(
'"%1$s” (%2$s) widget updated in %3$s',
'1. Widget title, 2. Widget type, 3. Sidebar name',
'stream'
),
esc_html( $summary_data[0] ),
esc_html( $summary_data[1] ),
esc_html( $summary_data[2] )
); This would produce an acceptable result in any language. It also keeps the terms "Hello World", "Text" and "Primary Sidebar" searchable. note: I purposely avoided translating the summary data. |
Yeah, I can see that my use of template variables like The problem with always generating summaries on the fly is that they cannot be searched. |
Lot's of discussion on the topic, it is starting to feel like gold-plating.
From my perspective, those four points are reversed in priority, eg: #4 is the most important concern, ordered by the user-base affected by the concern/problem. Reading through discussion:
So.. |
@shadyvb I agree with all of your points, and YES, performance is not a feature it's the number one requirement for Stream and the massive amounts of data that can result from using it. I thought Stream is already saving summaries and meta values according to whatever To me, this is perfectly acceptable, as @westonruter said, changing your site to a different language later is going to be a rare event. The more probable event would be if someone was using Stream for a while but their native language was not supported until later. My argument would be that if you decided to use Stream without your language officially being available, or if the translators don't keep up fast enough, then your old records will just have to be in the other language. I don't think there should be an expectation that we must always retroactively support a language either by an update routine or doing everything on-the-fly. I'm glad we had this discussion, but I think we've exhausted the conversation for now. We can safely close this and deal with any localization issues for meta values on a case-by-case basis. |
@ThemeBoy This is a discussion which I suspect doesn't have any sort of resolution. The idea here is that we're saving a "Summary" of each record. Of course, that summary gets saved using the language pack that's currently being used. This means that the summary isn't truly translatable. For example, if a site changes it's language, saved records will retain the old language. Also, if you are viewing the records for more than one site at once (think multisite) you may be seeing records in multiple languages. Any thoughts on how to achieve a language independent summary? |
This is huge one. I remember we've had discussion about it alread and some of you found that unnecessary. I must strongly disagree. Stream would be much more powerful if summaries were not saved directly in the database. Just a few arguments why:
It makes translation jobs more stressful. In the current state, translations should be updated with every release (and they are not). It's not a must for anyone to speak English and for some people logs in that language are useless, because they don't understand a word. If we update their language pack some time later, their logs will never be updated to the language they know.
Somebody might use plugins to make Wordpress multi-language on the backend, because they work in international team. The behavior here will turn into a beautiful mix of several languages.
We all make mistakes and those in logs messages can't be fixed.
We could want to make logs exportable one day, that would be something if we let users choose destination's language.
The text was updated successfully, but these errors were encountered: