• Hello Fabrik Community

    Fabrik is now in the hands of the development team that brought you Fabrik for Joomla 4. We have recently transitioned the Fabrik site over to a new server and are busy trying to clean it up. We have upgraded the site to Joomla 4 and are running the latest version of Fabrik 4. We have also upgraded the Xenforo forum software to the latest version. Many of the widgets you might have been used to on the forum are no longer operational, many abandoned by the developers. We hope to bring back some of the important ones as we have time.

    Exciting times to be sure.

    The Fabrik 4.0 Official release is now available. In addition, the Fabrik codebase is now available in a public repository. See the notices about these in the announcements section

    We wish to shout out a very big Thank You to all of you who have made donations. They have really helped. But we can always use more...wink..wink..

    Also a big Thank You to those of you who have been assisting others in the forum. This takes a very big burden off of us as we work on bugs, the website and the future of Fabrik.

Add "no change" option while creating labels

lcollong

FabriKant d'applications web
Hi,

If creating list tables from already existing MySQL tables (workbench), the element are created and a label is computed from the column name. In the Fabrik's params we have several choice to transform a column name into a proper label "automagically". That's nice.

But, if you want to build a multilingual site, you'll use language override to translate the labels constant to the the right localized text.

When the labels are created by Fabrik, underscores are replaced by white spaces. So user_Name could become "user Name", "User Name", "user name" or "USER NAME" but none of them could be used "as is" by language override feature which doesn't like white space.

So the first solution would be to add an option in the parameters (see snapshots) to leave the labels as the column name are. So "user_Name" would stay "user_Name" as a label. Thus you can add a constant to override the language the would say : USER_NAME="Nom de l'utilisateur" in french for example.

It would be better that this new option says "leave colum name as the are but all capitalized and replace any white space (?!?) by an underscore". A column "user_Name" would become a label "USER_NAME" as Joomla override mechanism is expecting capitalize letters in the constant (also it works with lower case).

Ideally we should be able to prepend all the labels with a fix constant in order to differenciate the constants of our own Fabrik's app from these coming from Joomla or others components (USER_NAME is probably used by the Joomla users management parts).

So we'd have a field to enter a fix constant : "MY_STUFF" and the labels would be created as :

MY_STUFF_USER_NAME

making this constant unique and easily manageable in the languages override files.

Could it have some hidden side effects ? At least the first solution should relatively easy to implement ?

Thanks for feedback.
 
Merged, although that doesn't address the issue of ...

Ideally we should be able to prepend all the labels with a fix constant in order to differenciate the constants of our own Fabrik's app from these coming from Joomla or others components (USER_NAME is probably used by the Joomla users management parts).

... which is a very valid issue.

I think a possible solution might be to have Yet Another Option on those choices for ...

COM_FABRIK_LABELS_LANGUAGESTRING_WITH_TABLE_PREFIX="All Caps and underscores, with the table name as a prefix (e.g. 'user name' from table 'mytable' becomes 'MYTABLE_USER_NAME'), usable as language string"

... rather than using some pre-defined slug, as this avoids the issue where you have two fields with the same name in different tables.

-- hugh
 
If you / Laurent have any opinions on which approach to use, let me know, I'll add whatever y'all decide makes more sense.

-- hugh
 
Thanks to both of you for adding this feature.
Regarding the fix slug / table name prefix choice, I think the first one has more flexibility as it makes sense that two fields from different table have the same label constant. A column named "first name" would always been translated as "Prénom" in french. Also, it's still possible to edit the element and change the constant to differentiate one from the other.
It's even possible to edit the Fabrik parameter before creating the list each time you do it. Thus manually introducing the differentiation.
The best of both world would to be able to use the "{thistable}" placeholder in the constant slug.
If we have a table "contacts" and a table "customers" with both a user_Name column, we'd have
Leaving empty : USER_NAME and USER_NAME
Simple slug (MY_STUFF) : MY_STUFF_USER_NAME and MY_STUFF_USER_NAME
Complex slug (MY_STUFF_{thistable}) : MY_STUFF_CONTACTS_USER_NAME and MY_STUFF_CUSTOMERS_USER_NAME
 
Sounds reasonable.

Remind me when I get back from vacation, if I don't get round to it this weekend. I'm out of pocket all next week.

-- hugh
 
It's on my radar, might be a few more days till I get round to it, I'm still busy playing catchup. It's usually a 1:1 relationship between the days I take off, and the days it takes to get caught back up on basic support to the point I can start doing dev work again. So probably Sunday or Monday.

Bump again on Monday if I haven't gotten back to you.

-- hugh
 
It's on my radar, might be a few more days till I get round to it, I'm still busy playing catchup. It's usually a 1:1 relationship between the days I take off, and the days it takes to get caught back up on basic support to the point I can start doing dev work again. So probably Sunday or Monday.

Bump again on Monday if I haven't gotten back to you.

-- hugh
 
Yeah, I haven't forgotten, just busy with administrivia. We're working on a long overdue migration to a new site, and revamping our subs model.

It'll be next week before I can get to it.

-- hugh
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top