Project renaming ?

i have implemented the site information interface intentionally different
from menu or taxonomy, starting from the code of Troy, because that user
interface is too reach. There are too much fields, as you said some time ago.

Translating the information in one page is useful and simple, but you have to change
language every time.

> I think we should get at least some link or textual hint to change language
Yes, this is another problem.

I am thinking also to another options, using Ajax, with a pop div where you can
select the language and insert the translation value of the field.
The popup should be placed near the original control and this perhaps
could be the less invasive way.
Extending the form with some tabs, like "Translations" and then put the similar
interface described in the previous approach ?
We could use Ajax as well to load and save data in this separate window.

>Which/how many translations do we store?
>would save some (negligible amount?)
Yes. It makes no difference one more translation on the db.

I think we should store everything, because someone could use Drupal
with a different language from English as base language.
Besides if he/she decide in the future to change its base language,
our assumption would be wrong.

If we store everything we are ready for every situations of this type.
Of course you are not obliged to insert also English language. If no
value is find, the default is used.

The AJAX submission of translated content would be extremely useful. Very user friendly and would add another desired feature to this already well designed module.

The tabs for forms (where large text strings are to be translated) would allow translators to toggle between the orginal and their translated version. This too would be really really useful to translators. In our office we have firefox with tabs of the orginal and the translated version, which allows toggling between the two. An tab above the formfield, with drop down list of locale languages and an AJAX save would be so much more effective...not to mention stylish!

>Btw: did we want to do some file and submodule renaming or is that postponed?
Now it seems to me we have time to discuss and change for the next release.

The new naming scheme must be coherent also with the db tables, of course.

So ... the last proposal was :
Main module : localizer, don't touch.

Submodules
loc_menu
loc_node
loc_taxonomy
loc_siteinformation
loc_user

and so on

Comments ?

Main module : localizer, don't touch.

Submodules
loc_menu
loc_node
loc_taxonomy
loc_siteinformation
loc_user

why changing the file naming schema? i think this should start with "localizer*"... as all modules, functions and so on are named in drupal. i think it is no good idea to change this. additional the sorting in admin/modules will change :-(((

@Ray
>as I've already said, I have no idea how you could put tabs on a page
>like "site information" that doesn't have any in the original. I gave up on that after
>some days searching, and not getting any useful help in the forums either.

Ok. You have already explored this way with no success, so we can discard it.

The other option is Ajax with a layer near the field to translate.
Form API doesn't have a similar feature : adding something near
a filed.
Or we use the description field, putting there a link, or we have to work
in Javascript to dynamically add a link with the Javascript call
near the field to translate.

Ok, perfect.
We have some very good start points.

I have to fix yet some minor bugs in the "initial detection language".
Then I would like to have a final decision for the new naming schema.
I am yet thinking to a good way to shorten the names.
I am thinking to shorten also the localizer module, without changing
the name of the project, to be more coherent.
I'll post my proposal later.

I'll work on these issues.

In meantime, Ray, would you like to experiment something
for the new translation interface ?

My idea would be to have a layer with :
- one combobox where the user can select the language
- one field (textfield or textarea) where to insert the translated version
- one button to save the translation

When you open the layer or change the language
we have to read the value from the db by Ajax calls.

So, I think that a "popup" layer would be better, so
we don't touch the underlying form structure of the page.

About the shortening of the names.

I see that lc prefix is widely used in the localization world,
and it recalls for everyone the words localization and localizer.

So, I propose :
- don't touch the name of the project : Localizer
- main module become : lc.module
- submodules become :
lc_node
lc_menu
lc_taxonomy

Comments ?

>No vote on renaming the main-module, your call.

I think :
- we maintain the order of the modules in the list
- we maintain the coherence in the entire naming scheme

We'll have a main module : lc.module, that owns all the submodules :
lc_*, a sort of hierarchy, if you want.

Changing the names would yield shorter function names, which imho is a good thing.

This sounds not like a good technical, clean and logic solution. I understand where you come from, but this sounds like the typical / unexperienced beginner developer phenomenon... however long you do development or not. After some or many years you will change your mind and learn, to do everything logic, clean and NOT being lazy. Let's say, shorten the name is only laziness and nothing more. It have nothing to do with clean, understandable and very good code. This is why every function in drupal should start with the module name. another side effect will come up, if someone will create a module and name it "loc" you and the other developer will be in troubles. And you cannot say for sure this will never happen.

I'm really sorry for this...

if you change the whole module name, ok... but this this is somewhat different. inside one module all should be clean.

Aside, why not using the typical i18n names... ok i18n (internationalization) is not available any more... but G11N (globalization) is free, isn't it? :-). All in reference to http://www-306.ibm.com/software/globalization/icu/index.jsp

please, read this about the wording... sounds good: http://www.translationdirectory.com/article127.htm

Hass has expressed some very good thoughts about the idea of changing
the project name / prefix.

Yes, G11N, would seem a good idea,
globalization seems to be the more advanced definition,
but changing the entire name of the project is not an option now.

The discussion will continue until we'll find a valid agreement.
Until then, nothing will change.
We already have enough work to do :-).

If we'll adopt the prefix g11n for the modules of this project, what name
could have this project ?
Perhaps ... GEN ? (G Eleven N)

Only some Ideas:

1. Globalizer *G*
2. Globalization (same way how Localization is named)

Mhhh ... Globalizer sounds good.

@Roberto: if i come from the translation side i like "globalization" more... or something other - that is easier to translate into different languages :-). However i have no problem with "Localizer"...

Ok, Hass.
What is your opinion about using lc has prefix ?
Has a sense for you ?

Thanks.

I guess I'll throw my hat in the ring.
IF the name is changed (and for me that is a BIG IF), then probably we should try a name that has some real "layman's" meaning and also doesn't ruffle the software folks' feathers at the same time.

For all you software folks out there, doesn't "Globalizer" sound like you are going to do something with variables?

What about the term "Multilingual" as the name? It certainly conveys the meaning well, and kind of works well grammatically too. (Ex: "I'm using the Multilingual module and it is working well for me.")

I'm not one to say if that means the prefix becomes ml_ or not.

Anyway "Multilingual" is just a thought. I shudder to think of what changing now means for Roberto.

g11n... may be l7r for l[ocalize]r? :)
I think that lc_ is ok, though it can't be pronounced easily, and again it reminds me about C :) .. that's why I like loc_ more

My point is only - if you'd like to shorten the technical module name, do it clean and everywhere, please. This means the module must be named "lc.module" located in "modules/lc" folder and not "localizer.module" and the submodules named for e.g. "lc_node.module" and so on. Mixing this up will create foreseeable troubles in future. Keep things easy and clean... only this becomes a future save win-win situation.

Please let me say, i don't really understand this discussion. Changing a module name only for laziness of writing some chars sounds crazy for me. The name "Localizer" is not wrong and sounds more memorable then "lc".

hass tells the right things, really.. we shouldn't have two technical names, we should have one.

Localizer will not change name. It is already widespread and it isn't a wrong name
for this project.
I'll see if, for technical reasons only, has a sense to use an abbreviation instead
of the complete name.
In this case also the main module will be renamed and the db tables too.

I'll take a deeper look at the Drupal naming rules and the I'll decide.

Thanks to everybody for your comments.

We cannot use _ (underscores) in the name of the files.
It may be confused with the method names ...

For example, lc_menu could be the hook for the menu
in lc.module and also the name of the file for the submodule
lc_menu.

We'll use : lcmenu.

I've tried to rename some modules to understand what is necessary.
It is a nightmare ... all the install procedures should be modified
to check if the tables already exists, if not, create them, rename
all the tables.
This change could break all the installations of the user.
It isn't a good idea for now and I don't have enough time
to make also this now.

-1 for renaming localizer.
-1 for abbreviations (Drupal core doesn't use abbreviations for well known reasons).
-1 for different (sub-)module names.
-1 for providing sub-modules that do not need to be modules.

Localizer 2.0 will implement include files instead of sub-modules. Just give me one use case where you wouldn't want to enable support for translating menus, variables, blocks or nodes. Enabling and disabling all these modules to have full multilanguage support in the modules list are simply 4 unnecessary clicks.

The new implementation allows support for arbitrary external modules, too.