[wp-trac] [WordPress Trac] #28571: Language updates problems
WordPress Trac
noreply at wordpress.org
Fri Aug 15 07:34:36 UTC 2014
#28571: Language updates problems
--------------------------+--------------------
Reporter: pavelevap | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: 4.0
Component: I18N | Version: trunk
Severity: major | Resolution:
Keywords: | Focuses:
--------------------------+--------------------
Comment (by pavelevap):
markoheijnen: Thank you!
1) Safe location
Yes, assumption that `wp-content/languages` is safe can be bad, but really
used. I did not notice that mentioned examples use other subdirectory. But
see for example following links:
https://core.trac.wordpress.org/ticket/23721 (and others). Users need some
safe directory for modified localization files (and they use `wp-
content/languages` now, especially for plugins and themes).
https://wordpress.org/plugins/codestyling-localization-preserver/ Plugin
to preserve modified localization files.
There was need for users to modify localization files, because of plugin
and theme updates overwriting localization files. So, users started using
`wp-content/languages` and nobody told them not to do it. And we have to
deal with it even with WordPress core, because there will be more problems
with themes and plugins. And overwriting modified localization files is
not a good solution.
2) Approved language updates
I am not sure, why we can decide not to update WordPress, plugins or
themes, but language updates are forced as default. I understand that it
should work automatically for users not to bother them, but current
(trunk) state is not ideal.
What about selection of available languages updates? Users can select what
can be automatically updated (and they can change it in the future). It
can be as simply as plugins or themes. Users can check WordPress, Akismet
and uncheck Twenty Fourteen, because they have own customization here. And
users know what will be automatically updated (no strange and hidden
process in the background). And in this case we can forget for point 1,
because users can simply choose not to update. Everybody happy...
3) Do not overwrite developers installations
I tried to add following code to plugin file (or functions.php in 2014
theme):
`add_filter( 'auto_update_translation', '__return_false' );`
Language updates still coming :-( Maybe it is due to SVN localhost
installation? I am not sure, but it is really annoying because of using
Poedit and my files are always overwritten.
4) Distribution of translation
I still think that some kind of button (checkbox per project in GlotPress)
is needed. Instead of packaging the whole localized version, there could
be a simple checkbox for every MAJOR version (minor can work
automatically). It is still great improvement for translators, only one
checkbox per project (for WordPress it should combine all subprojects), no
problem with handling minor versions, etc. Translators could check when
they think it is done and distribution can start. No script can find that
localization is ready to use! As I wrote in my example (frontend 100%,
administration 90%, multisite 10%), localization is ready and standard
user does not notice any English strings. How can script do it? When
administration was 88%, we did not want to allow distribution, because of
About page was not complete (and every users will see it). So 88% for
administration was not ready, but 90% was. In the next major version it
can be different. No script can handle it and if it will be done in this
way, translations will be postponed until 100% (so many users will not
have their localized version, even if it is ready for using).
5) More languages
I tried Slovak version, but do not use it now. I do not want to
automatically update all languages versions I tried in the past. How can I
do it? Why there are inefficient checks for files which are not used? It
can be automatically updated when I switch back to Slovak version? Users
will be annoyed, because they can see that Slovak version is updated too
and they do not know why (they forgot that they tried this version in the
past).
6) Never ending out of date message
See new ticket: #28949.
7) Problem messages
Screenshots with errors are still valid. Also string "Updating
translations for WordPress (cs_CZ)" is displayed several times and user do
not know what is happening behind...
I can create new tickets for some of these issues, but some points in
current state are BLOCKERS (regression, bad user experience, overwriting
files), I guess.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/28571#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list