Locaprofile - port of i18nprofile to localizer

BTW, I named it 'locaprofile' as it sounds shorter than localizerprofile. The naming like 'localizerprofile_translation_overview' seems too bad for me, really. I'm lazy :)

Thanks Troy!

I'm giving it a test run.

>May be someone (may be me?) will have time to make it to save its data in localizertranslation table
Yes, it is better if we can use the localizertranslation table.

>I named it 'locaprofile' as it sounds shorter than localizerprofile
I don't like to break the naming scheme :-).
Leave so, at now, but before the official release we have to found a solution.

>'localizerprofile_translation_overview' seems too bad for me
No problem for me :-).

If we decide to change the prefix, we have to change it everywhere.
For me it could be acceptable also to use "loc" as prefix.
The only important things are :
- it must be related to localizer, so the user can easily identify it
- must be unique in Drupal

I propose loc :
loc.module
locmenu.module
loctaxonomy.module
locviews.module
locnode.module

What do you think ?

Let me know.

if you want to keep the localizer-prefix and shorten the names, just shorten the suffix, i.e.
instead of "localizerprofile_translation_overview" just "localizer_trans_ov" ?

a shorter module prefix may not be a bad idea for the sub-modules, but I'd seperate the "loc" from the rest with an "_".
i.e. localizermenu -> loc_menu ... makes the stuff imho more readable.

makes the cvs history a bit messy, but so what ;-)

> "localizerprofile_translation_overview" just "localizer_trans_ov" ?
If it is a method hook, we cannot change it.

Yes. cvs would become a nightmare :-), but I am not
worried about it. The only valid version for me is the latest
with this rate of changes !

Ok for for loc_menu.module, loc_node.module and so on.

We'll wait also the others opinions and then we take a decision.

I'm also thinking to align the versions numbers for the two branches : 2.8 both
for Drupal 4 and Drupal 5 in the next release.

I think we need to leave 'localizer_' prefix as is, and change only prefixes of submodules.
loc_vars.module
loc_profile.module
loc_block.module

or

locavars, locaprofile, locablock (easier to pronounce and faster to write, actually, but no real divider)

just shorten the suffix, i.e.
instead of "localizerprofile_translation_overview" just "localizer_trans_ov"

it as incorrect to shorten function names to something unmeaningful, there will be few people who know what-this-function-do and other developers would have to read comments and docs to realize what's going on. By the way, the localizer already have strange function names, I mean c-like localizer_get_currobjfieldtr(), etc. I'd better write localizer_get_current_field($obj), as it makes sense and I realize that I'm writing for Drupal in Drupal style :)

> localizer_get_currobjfieldtr(), etc. I'd better write localizer_get_current_field($obj)

Yes, I must admit that I am not particularly pride of the method names
of the translation engine.
My main concern was to have names with a complete reference to the feature.

tr : for translation (engine)
curr : current
obj : we are translating an object
field : we are translating a field

But I admit it is unpronounceable as name.

We can change it !

Your proposal is valid for me.

Troy, wouldn't you like to have an access to localizer cvs ?

Let me know.

I thought _trans_ov to be a still quite readable shortening of the original name, but opinions on such things differ of course.

And for localizer_get_currobjfieldtr() ... it seems to me like an internal function, and should probably begin with an "_"?
People working on the core can be expected to read documentation and comments ...

And a final comment to sub-module prefixing:
I (surprise) prefer the "loc_" version, though it has 1 small drawback: the word "location" also starts with "loc" ... but that shouldn't cause us headaches, right?

> And for localizer_get_currobjfieldtr() ... it seems to me like an internal function, and should probably begin with an "_"?
It is more than an internal function, because it could be used externally also from other modules.

It is an API of the translation engine.

If we can find a coherent naming scheme for all this methods, there is no problem for me
to change them.

About renaming.

localizer module untouched.
submodules : loc_

tr : for translation (engine)
curr : current
obj : we are translating an object
field : we are translating a field

But I admit it is unpronounceable as name.

When I started writing for localizer, I thought that tr is mysql table row :) I think it is a good step to make the readable code.

And for localizer_get_currobjfieldtr() ... it seems to me like an internal function, and should probably begin with an "_"?

If I'm not mistaken, it is one of localizer API functions. And at least these API functions should have drupal-style and readable name (to save time) and effective code (to prevent submodule developers from writing db_query() to localizertranslation as I did in localizervars)

Troy, wouldn't you like to have an access to localizer cvs ?
Let me know.

I'm not sure that I will be active localizer developer for all the time. I need to finish my multilingual project and then I'll realize if I have time to support localizer development.
Thank you, Roberto, I'll let you know.

if localizer_get_currobjfieldtr() is an api-function, than of course no underscore at the beginning.
It would help readability already, if it was called localizer_get_curr_obj_field_tr(), so I can see the word boundaries at first glance.

shortening words to commonly used versions is something I also do, though my currents have only 1 r -> 'cur' ;-)

the question of word-order is always a question of hierarchy, what do I want to have, and what are further qualifiers, and therefore at the end of the name.

so maybe (wild try):
you want to get

• the translation
• for a field of an object
• and the object is the current one

so I don't yet know if its "obj_field" or "objfield", but
localizer_get_tr_obj_field_curr() may not be a bad name?

or some such scheme ;-)
and you sure know the hierarchies better than I do

Is this still available ? And does it work? I am looking for a solution to translate customized profile fields.
Any pointers much appreciated.
thanks,