Formatting string in camelCase

Hi,

“camelCase” formatting is very common for storing strings in a compact and efficient yet readable format that can be converted back to “natural” - unlike say the concatenated lower case format.

That’s why I think it’s good practice to use them for the i18n files for instance.
Or maybe you know a better practice?

So I was wondering whether anyone already came up with functions to camelize and uncamelize a string?

Like this string to thisString and the other way around (i tend to prefer “lower” camelCase but I wouldn’t mind the “upper” alternative like ThisString).

Of course, it would be even more convenient to have hugo provide this function like humanize, title etc. Or maybe it does already? I couldn’t find in the docs…

Thanks for your help!

I did not test it but probably something like this might work:

{{ Textvariable | title | replace " " "" }}

title makes every word start with an uppercase character and replace should remove the spaces.

Hi!

Thanks for your help!
Simple yet efficient solution.

It doesn’t address all situations though…

I had in mind something like this (not tested just for the logic):

For camelize:

{{ $input  := This string }}
{{ $sliced := slice (lower $input) }}
{{ $first  := first 1 $sliced }}
{{ $rest   := trim $sliced $first | title }}
{{ $output := print (delimit $first $rest "") }}

Output should then be thisString.

For uncamelize:

{{ $output := thisString | replaceRE "(?<!^)(?=[A-Z])" " " | humanize }}

Output should then be This string.

Limitation to this approach is that strings with abbreviations will be formatted wrongly:

  • with abbreviation as first word:
    “RSS Title” => “rssTitle” OK => “Rss Title” (should be “RSS Title”)

  • else with abbreviation in rest of the string:
    “we like FOSS” => “weLikeFoss” (should be “weLikeFOSS”) => “We like foss” (should be “We like FOSS”).

So maybe a solution could be not to lower the whole string and keep upper cases if precedent slice is upper and of len 1.

I’m sure its possible to come up with a better solution.

How should Hugo know that rss is an abbreviation? It’s three characters. There is no dictionary of any language in these string functions. There is definitely no “better” solution to come up with.

Sample:

“SOME Title” => “SomeTitle” => “Some Title”.

It’s just characters. Why would any string function understand that SOME is uppercase? If you add a map of terms that are abbreviations you might be able to use a data dictionary to move through all single words and see if they match a term and then use uppercase on them. Every time you have a new term you need to add that term to the map. But that is such a specific way that it makes no sense. No sense as in “buying a mercedes car to play a cassette tape”.

I would understand if the camel case of “RSS feed” would be “RSSFeed”. THEN you might be able to create a regexp that looks for multiple uppercase characters and then use n-1 characters for one uppercase term and n+all following lowercase characters as the next term. Expecting RSS to go to Rss and back to RSS is impossible.

Wait, what exactly is your use-case for this? What are you trying to achieve? It’s probably better to not even think about camel-case and use frontmatter for this. It’s a bit of manual work to add the proper params, but you will save the work trying to achieve something more complicated.

You’re right, it was foolish to think we can get RSSTitle back from rssTitle.

I was actually trying to be consistent with hugo’s convention but definitely if the string contains abbreviations as a first word it should then be set in upper case.

Maybe you’re solution is indeed the best one after all.

I’ve actually found a working regex to uncamelize the string.

My actual use case: in multilingual mode, I find it more convenient to store my taxonomy terms in english and use i18n files for translations. So I’m trying to fix my translation files with an uniform naming convention… and print them nicely.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.