jules

This is my interpretation of the events unfolding before our eyes. This is my guess:
WP core developers are still looking into the translation issue. When they are ready they will publish the official -or right- format for language files. It is a complicated choice. There are several issues to consider.
In the meanwhile we will have to do with the language file format (and method of translation) provided by the WP Multilingual Edition. This file format you find currently on WP Wiki Localization pages. – This language format is an ‘easy’ or ‘common’ format. Nothing wrong in that. It is very good.
To use this ‘easy’ or current lang file format you have to use WP Multilingual Edition. The lang files work only with it. If I am not mistaken the Multilingual Edition is maintained by Otsukare. If there are functional changes to WP the same changes will be made to Multilingual Edition as well. Find your updates there.
I believe what we have here is a parallel version of WP. It simply fullfills the needs of multilingual users in the short term. It is not a fork. Something was bound to fulfill the void: after almost 2 months there is still no official lang file format available.
If you translate the strings and use the current lang file format your work will no be in vain. Whatever the right file format will be the same strings will have to be translated. But it might involve a lot of ‘cutting and pasting’ when converting.
As for whether a particular translation is complete or not – I have not installed the Multilingual Edition. But having done some translating in the past there are always odd sentences deep down that are left in English. Even in programs that have claimed to be fully multilingual for several years. To hunt down those we need community effort. – So, a lot of work ahead.
I hope I did not offend anyone…

I spent some more time with Color wheel:
There is a learning curve to color wheel: First you learn to appreciate the “reset” checkbox. But after many attempts one starts to get the joy of discovery: “WOW – I couldn’t have have visioned that effect on my own”.
It’s greatest asset is that it changes almost everything at once – it is a speedster. The approach I proposed could not do that – it is a sloth.
As you point out it could be “…adapted further…separating controls for backgrounds versus text”. In many occasions I got great colors but the text was unreadable. Some form of selective control is needed. I mean: It would be useful to freeze e.g. some colors and tweake text colors further. Or freeze the header and correct the menu background or text.
If I understand correctly very much depends on what color values (‘seed’) the original CSS file has. Color wheel allows to explore starting on that premise. If all colors are white it is unable to tweak, correct? – If so, it needs a way to modify the ‘seed’ color values. Say I want to get a bluish or greenish design. I should be able to start quickly into that direction.
I guess the problem here is to combine easy exploration and easy (selective) control? Color wheel demo is advanced tweaker’s tool good for color exploration purposes. It shows what advanced controls could be made available. It is a first.
Would it be possible to develope it in a way that would have NO need to modify the current WP ‘infrastructure’. I mean to make it a ‘module’ that can be added. It would alter the contents of the CSS file only as it currently does (correct?). This way its development would not take any resources away from the core development.
This is just my opinion but I think this avenue should be explored. It would expand the available colors schemes and (possibly) provide an easy way for an admin (user?) to customize his site AND retain WP’s aesthetically pleasing text styling. Let Lazy admins to play with the colors and leave advanced subject of text formatting to WP .css developers? WP’s original design concept (pleasing text) would prevail and unlimited color variations would be ‘available’ for each different design.
greetings, jules

Hi Andrew_h
I find your project very interesting. For a past few days I’ve been playing with almost the same idea – Dynamic CSS color adjustment (yes, typing the colors is boring). There is a need for it. I will join my ideas with your thread since I have no programming skills.
Idea: “Lazy Admin Tool #1 – BG Colors”
The objective would be to develop a tool which would enable every admin (member, user too?) to point and click his/her favorite colors and then update the CSS. Voila, the blog has a new color scheme.
Reason for doing it:
Thanks to recent CSS competition WP now has a wealth of wonderful styles and layouts. But as the user base of WP grows to many thousands it will not be enough. There will be countless sites who will be using unaltered CSS files. It will be rather boring (seen it happening elsewhere).
WP is rather standardized and CSS based. It should not be impossible to write such a tool. Lazy admins (many of us?) will then pick a wonderful design and change its colors simply by pointing a color and clicking.
************
This is how I imagined it would work (please add in all technical stuff I do not know):
The sript would scan the CSS file and find every ” background: #XXXXXX; ” tag. It would extract this data and name these with their class names (e.g., BODY, HEADER, MENU, COMMENTFORM, …) or simply with alphabets: Color A, B, C, …
Then it would print a standard (index?) page using the same CSS. It would insert into that page a form which has the following content:
Description—color_value—color_sample/preview_of_size_x_by_y
[BODY color:] [aaaaaa] [size x by size y color sample of color aaaaaa]
[HEADER color:] [bbbbbb] [ x by y color sample of color bbbbbb]
[MENU color:] [cccccc] [x by y color sample of color cccccc]
…
A small window would pop up. It would have a selection of ‘available/ web safe?’ colors and your (andrew_h) CSS color wheel functionality?
Usage:
First click a row (radio button?) and then click a color on the pop up window. The new color would replace old values. Then repeat for the next row. Finally click update and the site will have new color scheme. Repeat and change some colors till satisfied.
I have borrowed ideas from these sites:
https://www.csscreator.com/version1/index.php
https://www.csscreator.com/version2/pagelayout.php
If more interaction is technically possible it would be welcome. For example choose HEADER color row to edit, choose a color, and the color of the page header would change instantly …
I have not seen such a tool in any other blog – anyone?
*************
It is SO easy to daydream: “Lazy Admin tool #2 – Text” ; “Lazy Admin tool #3 – Spacing” ??
Cheers!

I am kind of jumpy about the split (word) – seen *nuke enough.
Premilinary notes:
There are three (3) types of changes:
1) Change in the way strings are written (into the code. As done by Otsukare.)
2) Changes (to the code) made by the localization team to achieve better operation in foreign lannguages.
3) Changes (to the code) made by the developers to add features or improve functionality, etc.
Smooth localization will be a long process. It might just happen that #3 gets far ahead if developed separately. It will be a real struggle to integrate the lines of development in case separate type #2 changes are numerous. You see, there would be changes going both ways. It could be a mess.
***********
NON-split development:
The task will be easier if the task if executed in two (2) phases: A and B.
A) First integrate type #1 changes into the code.
Language is English. – This would yield a WordPress that does not offer any improved localization features. It would be plain vanilla WP 1.01 in English. In other words (English language) strings are in a lang file and not hardcoded into the code.
Steps to achieve this:
The current localized WP 1.0 code must be upgraded to reflect the changes in 1.01 (1.02?). I assume it contains type #1 changes ONLY. This would take a few days. During that time current development tree should be freezed.
(I do not know about CVS much, excuse my ignorance.) The new localized WP 1.01 would be loaded into (a new?) CVS and then tested by the development team. If everything is OK it will become the new WP 1.1X. It will be in English only and functionally equivalent to the 1.01 / 1.02 (moment of freeze).
B) Development will continue.
The developers will continue to do what they want to do, type #3 changes. They would be in charge. Base language would be English.
Localization team will do/ propose type #2 changes to the CVS (discussed somewhere).
Translators will translate various language files (Wiki collaboration).
This would lead to gradual development (evolution). There would be no integration crash looming in the horizon.
**********
I know this is a lot to ask. It would affect us all. It has to be agreed by everyone, starting with main developers. – I see this as an opportunity not to be missed. If the current proposed localized English version is OK it should be integrated before it falls too far behind. Early integration would save work in the long run.

This is exactly what i needed! – Many, many thanks Otsukare!