Automatic phrase type based on it's name

[Alexander Obuhovich]

I think, that we need a way for In-Portal to automatically guess phrase type based on:

• user action (that leads to user to phrase adding/editing screen)
• phrase name (that is entered by user)
  

By User Action

• translation phrase while on Front-End (special translate link OR orange edit button) - "Front-End" type;
  
• toolbar button "Add" click in phrase list in administrative console - "Admin" type.
  

By Phrase Name

• phrase name starts with "lu_" - "Front-End" type;
  
• phrase name starts with "la_" - "Admin" type.
  

Detection by phrase name overrides detection by user action, since it's bad style to mark phrases, that starts with "lu_" belonging to administrative console.

When both "Phrase Name" and "Phrase Type" fields are visible on phrase adding/editing form, then I also suggest to place "onblur" event on "Phrase Name" field to change "Phrase Type", when user starts to enter phrase translation.

In this case we could make "Phrase Type" field read-only to user. There is one small problem with that: phrases, that have "Both" type. We should eliminate that as soon as possible, but in this scheme their type will be changed automatically based on their name.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Dmitry Andrejev]

I like the idea - sounds like feature for 5.2.0 or future.

Here is the list of phrase with Both type:

==========

<PHRASE Label="la_importlang_phrasewarning" Module="Core" Type="2"><![CDATA[Enabling this option will undo any changes you have made to existing phrases]]></PHRASE>

<PHRASE Label="la_PhraseType_Both" Module="Core" Type="2"><![CDATA[Both]]></PHRASE>

<PHRASE Label="la_prompt_DupRating" Module="Core" Type="2"><![CDATA[Allow Duplicate Rating Votes]]></PHRASE>

<PHRASE Label="la_prompt_DupReviews" Module="Core" Type="2"><![CDATA[Allow Duplicate Reviews]]></PHRASE>

<PHRASE Label="la_prompt_overwritephrases" Module="Core" Type="2"><![CDATA[Overwrite Existing Phrases]]></PHRASE>

<PHRASE Label="la_Text_backup_access" Module="Core" Type="2"><![CDATA[In-Portal does not have access to write to this directory]]></PHRASE>

<PHRASE Label="la_Text_Invalid" Module="Core" Type="2"><![CDATA[Invalid]]></PHRASE>

<PHRASE Label="la_Text_Not_Validated" Module="Core" Type="2"><![CDATA[Not Validated]]></PHRASE>

<PHRASE Label="la_users_subscriber_group" Module="Core" Type="2"><![CDATA[Assign mailing list subscribers to group]]></PHRASE>

<PHRASE Label="lu_field_cachedrating" Module="Core" Type="2"><![CDATA[Rating]]></PHRASE>

<PHRASE Label="lu_field_cachedreviewsqty" Module="Core" Type="2"><![CDATA[Number of Reviews]]></PHRASE>

<PHRASE Label="lu_field_cachedvotesqty" Module="Core" Type="2"><![CDATA[Number of Rating Votes]]></PHRASE>

<PHRASE Label="lu_field_createdbyid" Module="Core" Type="2"><![CDATA[Created By User ID]]></PHRASE>

<PHRASE Label="lu_field_createdon" Module="Core" Type="2"><![CDATA[Date Created]]></PHRASE>

<PHRASE Label="lu_field_description" Module="Core" Type="2"><![CDATA[Description]]></PHRASE>

<PHRASE Label="lu_field_hits" Module="Core" Type="2"><![CDATA[Hits]]></PHRASE>

<PHRASE Label="lu_field_hotitem" Module="Core" Type="2"><![CDATA[Item Is Hot]]></PHRASE>

<PHRASE Label="lu_field_lastpostid" Module="In-Bulletin" Type="2"><![CDATA[Last Post ID]]></PHRASE>

<PHRASE Label="lu_field_linkid" Module="Core" Type="2"><![CDATA[Link ID]]></PHRASE>

<PHRASE Label="lu_field_manufacturer" Module="In-Commerce" Type="2"><![CDATA[Manufacturer]]></PHRASE>

<PHRASE Label="lu_field_modified" Module="Core" Type="2"><![CDATA[Last Modified Date]]></PHRASE>

<PHRASE Label="lu_field_modifiedbyid" Module="Core" Type="2"><![CDATA[Modified By User ID]]></PHRASE>

<PHRASE Label="lu_field_name" Module="Core" Type="2"><![CDATA[Name]]></PHRASE>

<PHRASE Label="lu_field_newitem" Module="Core" Type="2"><![CDATA[Item Is New]]></PHRASE>

<PHRASE Label="lu_field_notifyowneronchanges" Module="Core" Type="2"><![CDATA[Notify Owner of Changes]]></PHRASE>

<PHRASE Label="lu_field_orgid" Module="Core" Type="2"><![CDATA[Original Item ID]]></PHRASE>

<PHRASE Label="lu_field_ownerid" Module="Core" Type="2"><![CDATA[Owner User ID]]></PHRASE>

<PHRASE Label="lu_field_popitem" Module="Core" Type="2"><![CDATA[Item Is Popular]]></PHRASE>

<PHRASE Label="lu_field_postedby" Module="In-Bulletin" Type="2"><![CDATA[Posted By]]></PHRASE>

<PHRASE Label="lu_field_priority" Module="Core" Type="2"><![CDATA[Priority]]></PHRASE>

<PHRASE Label="lu_field_resourceid" Module="Core" Type="2"><![CDATA[Resource ID]]></PHRASE>

<PHRASE Label="lu_field_status" Module="Core" Type="2"><![CDATA[Status]]></PHRASE>

<PHRASE Label="lu_field_topicid" Module="In-Bulletin" Type="2"><![CDATA[Topic ID]]></PHRASE>

<PHRASE Label="lu_field_topictext" Module="In-Bulletin" Type="2"><![CDATA[Topic Text]]></PHRASE>

<PHRASE Label="lu_field_url" Module="Core" Type="2"><![CDATA[URL]]></PHRASE>

<PHRASE Label="lu_of" Module="Core" Type="2"><![CDATA[of]]></PHRASE>

==========

I'll work through it to make sure LA or LU indicates where it's used and we don't have missing phrases after we implement this functionality.

DA.

--

Best regards,

Dmitry A.

[S.G.]

I began thinking about bringing "Both" type back to life already some
time ago. If we'll use it in correct way, marking all phrases used
both on front-end and back-end (for ex., field options like
la_opt_Yes, la_opt_No), it would make much sense for translators. In
several cases translator wants to translate only front-end phrases
(when there are few languages on website and only one language
actually used in administrative console). There also may be cases when
only back-end phrases are to be translated. So, marking la_opt_Yes as
admin phrase hides it from front-end translator who uses type filter,
but phrase actually may be used on front-end also, if same field's
value is outputted somewhere on front-end. Using "Both" type would
make it more clear.

> On Tue, Aug 31, 2010 at 1:00 PM, Alexander Obuhovich <aik.b...@gmail.com>wrote:
>
> > I think, that we need a way for In-Portal to automatically guess phrase
> > type based on:
>

> >    - user action (that leads to user to phrase adding/editing screen)
> >    - phrase name (that is entered by user)
>
> > *By User Action*
>
> >    - translation phrase while on Front-End (special translate link OR

> >    orange edit button) - "Front-End" type;

> >    - toolbar button "Add" click in phrase list in administrative console -
> >    "Admin" type.
>
> > *By Phrase Name*
>
> >    - phrase name starts with "lu_" - "Front-End" type;
> >    - phrase name starts with "la_" - "Admin" type.

>
> > Detection by phrase name overrides detection by user action, since it's bad
> > style to mark phrases, that starts with "lu_" belonging to administrative
> > console.
>
> > When both "Phrase Name" and "Phrase Type" fields are visible on phrase

> > adding/editing form, then I also suggest to place "*onblur*" event on

[Alexander Obuhovich]

So you think, that "Both" phrase type isn't so bad after all.

Maybe we should invent new phrase name prefix like "lc_" (label common) or "lb_" (label both) to indicate, that phrase is used both on Front-End and Admin.

In this case we can still guess phrase type by it's name. What do you think, Sergey?

Some phrases, like "la_prompt_DupRating" are surely a configuration variable name, that is visible only in Administrative console, but is used to configure forms on Front-End only, so it will became "Admin" type for sure. However phrases like "lu_field_cachedvotesqty" are used as search field names, that is visible in search settings section in administrative console and on advanced search form on Front-End.

[S.G.]

Also, one note about auto-detection phrase type in conjunction with
using "Both" type: we may add "type" parameter to m_Phrase tag, so in
case if it's given, it overrides auto-detection.

[Alexander Obuhovich]

Presuming, that "lc_" or similar phrase prefix will be invented, then we no longer need phrase type detection by user action.

It's really important for me to know, so I repeat my question:

Maybe we should invent new phrase name prefix like "lc_" (label common) or "lb_" (label both) to indicate, that phrase is used both on Front-End and Admin. This way we could make Phrase Type field read only for sure on phrase adding/editing form.

[S.G.]

Yes, we may add lb_/lc_ prefix also, but it will result in current
label renaming, which includes changing labels in templates and code.
It's too complicated, may be we can apply it for new labels only?

[Alexander Obuhovich]

I think that we will apply that new phrase name prefix to phrases on question for now (ones that have "Both" type right now) and in time we will scan at least all options of fields to rename phrases.

Most problems will be with "la_Yes" and "la_No" phrases, that will be renamed to "lb_opt_Yes" and "lb_opt_No" and most people have them hardcoded in their custom unit configs.

Sometimes little sacrifice must be made for a better future. I home sometimes In-Portal will be complaint to it's own naming standards.

[Dmitry A.]

Let's revisit this discussion.

Alex, as I understand this will stop Developer from ability force Label to one of 3 types as they can now and will be done automatically.

What are the down sides of this, if any?

DA

[Alexander Obuhovich]

This we note phrase usage in it's name by "lc_" prefix, so translator will know, that such a phrase is used on both Front-end and Admin Console.

Since phrase type will be 100% automatically determined by it's name (which is checked against regular expression now in 5.1.1+ versions), then no human-mistake could be made.

We could even prevent "la_" phrases from being used on Front-end at all (need to review whole language pack to ensure that this will work without problems).

[Dmitry A.]

Thanks for reminding and explaining.

I am all for it!

I say we can introduce this starting 5.2.0 if you don't mind.

DA

[Alexander Obuhovich]

We can introduce it even before that.

[Dmitry A.]

Ok, how about 5.1.3 then?

DA

[Alexander Obuhovich]

ok.

On Sun, Feb 20, 2011 at 8:53 PM, Dmitry A. <dand...@gmail.com> wrote:

Ok, how about 5.1.3 then?

DA

[Dmitry A.]

Alex, would you please create a task for this?

Don't want this discussion to get lost.

DA

[Alexander Obuhovich]

Task: http://tracker.in-portal.org/view.php?id=1024

[Alexander Obuhovich]

I've recently noticed, that lack of this automatic phrase type detection leads to tons of phrases designated for Admin Console usage (with "la_" prefix) having a "Front-end" type set upon their creation.

Since currently no automatic check is made, then user/developer could create a lot of misleading phrases (marked for admin user, but having front-end type and vice versa).

[Phil -- wbtc.fr --]

that's right, specially when using the special page for translating while surfing on front end, where user will likely not select any phrase type in drop-down.

What do you propose here? A little script which read all phrases labels in theme and set them to "front" if they are set to "admin"?

Or just adjust phrase type using their prefix la or lu ?

2011/9/2 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

I'm proposing to:

1. add "lc_" phrase prefix for phrases that can be used in both front-end and admin
2. make Type field of phrase set automatically based on phrase start "lu_", "la_", "lc_"

This way no mistakes and you export front-end and admin language packs without any problems.

Your idea about "little upgrade script", that would fix any mistakenly created phrases is useful too.

[Phil -- wbtc.fr --]

what would mean "c"? I was thinking about "lb_" for Language for Both

I though about this script before, because I was also thinking it cloud clean the lang pack: each front-end label not found in theme would be deleted. This would be a maintenance script, which could also apply for admin theme, in case users have chosen the wrong label type.

[Alexander Obuhovich]

"c" means "common for both front-end and admin" (that one is described in previous posts).

Detecting which phrases are actually used isn't easy task, since phrase could be used even if it's label isn't mentioned in template. And since we need to type phrase name in less places now, then change of detecting used phrase becomes even smaller.

However we do track used phrases per each front-end template. If you can visit all website pages, then based on collected data we can safely assume, that all other phrases of "front-end" type are no longer in use.

That's of course is matter of another "keep language pack up to date" discussion, that doesn't exist right now.

[Phil -- wbtc.fr --]

c for Common is better than my b for both :-)

right, let's dedicate another thread for lang pack maintenance ideas

2011/9/2 Alexander Obuhovich <aik....@gmail.com>