We're about to start refactoring a bunch of hard-coded text from a client's Lightning Components and Visualforce pages into Custom Labels so that they can support multi-language users. Unfortunately as you all know, these can't be sorted into folders or anything else better organized (although list view filters are possible).

Any thoughts on what makes for good naming conventions for a pile of Custom Labels? Some of these will represent one or two words, others entire phrases. Some of them will likely be reused between different pages.

Also because Lightning has no support for the same kind of $ObjectType.Account.Label syntax that Apex has, we'll probably have to also be storing some object and field name translations redundantly in Custom Labels. If our Lightning cmps were at a MUCH bigger scale I'd maybe consider building a custom service component to deliver object/field labels but that seems like overkill for the current project.


3 Answers 3


Even though it depends on teams to teams when it comes around best practices, but as for your question

Any thoughts on what makes for good naming conventions for a pile of Custom Labels?

I have usually taken an approach of reflecting the intent of the custom label in its name. Have also tried to keep the naming convention seamless so that it can be organized. I have mostly used below approach from best practices around naming conventions of custom labels:

  • Use uppercase letters
  • Separate words within the name using an underscore
  • Reflect the intent/characteristic of the label
  • Keep the overall length of the label name short

As an example, let's say if I have a some sort of legal text to be displayed somewhere, I would create a custom label as say, LEGAL_DISCLOSURE_TEXT. Similarly if I had something related to say finance, I would have it as FINANCE_COLLECTION_DAYS.

Again, it all depends on which approach you take, but usually starting right from design helps it from future maintainability and scale-ability perspective.


The most important part is consistency: don't name one label ERR_TOO_MANY_FILES and another VALUE_TOO_LONG_ERR. In my opinion, that's more important than trying to find the "one right way" (there isn't one). Document your naming convention, and stick to it. Also, aside from naming, make sure you're using the Categories field for each label. This will allow you to create custom List Views to easily find labels you're looking for.

  • 1
    Yeah I'm thinking it through... so far I've decided that single/plural object labels (b/c Lightning needs rendundant copies) will be prefixed OBJ_ / OBJS_ and field labels FIELD_. Short verb phrases will start with ACTION_ e.g. to ensure the translator knows the difference between book (v) and book (n). Phrases unlikely to be used anywhere but on one page/component are prefixed with an identifier for the page/component. Shared phrases not fitting any of these categories are prefixed as shared.
    – Charles T
    Jul 3, 2018 at 17:58
  • @CharlesT It sounds reasonable. Also, keep in mind that Lightning also has its format expression operator so you can use merge fields. Be sure to read the documentation.
    – sfdcfox
    Jul 3, 2018 at 18:05
  • 1
    Yup I was aware of that. Although I didn't notice until now that format "Supports ternary operators in labels and attributes." Ternary operators in the labels? Any syntax examples?
    – Charles T
    Jul 3, 2018 at 18:10
  • @CharlesT, We use the category to differentiate based on our scenarios like Button,helptext,errormessages,hardcoded. This also helps us easily filter out the hard coded from asking translations for them. Thats the only free text field in custom labels record which can help you organize things
    – RedDevil
    Jul 4, 2018 at 11:36

I like an adaptation of the naming convention from this blog:

"Define sensible categories for the labels. e.g. UI Button Label, UI Text, UI Error Message etc.

Name = [Category with underscores]_[Value with underscores] e.g. UI_Button_Label_Proceed

Category = [Category with underscores] e.g. UI_Button_Label

ShortDescription = [Category] [Value] e.g. UI Button Label Proceed

Value = [Value] e.g. Proceed"

I find taking the time to fill in categories ends up being really helpful in grouping Custom Labels, a very underused feature.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .