Language guidelines

Clear, concise language is essential and should be the guiding principle for all language in an application. Consistent language rules in an application are more easily understood by users. When in doubt, be consistent. Application builders should be careful to specialize default language that comes in the platform, so it's contextual to their users' needs.


  • Sentence case is the default casing for anything not listed below.
  • Title case is used for page headers and navigation items referencing those pages (e.g., "My Worklist" and "Go to My Worklist"), people, places, things, and book, speech, or article titles (e.g., “War and Peace”, not “War and peace”). Update: Case types no longer use Title Case (e.g. "This is a bug..." , not "This is a Bug...")
  • All caps is used for statuses, tags, and the application name. NOTE: Type “All caps” items in sentence case. Use formats / CSS to transform to “uppercase” as some screen readers read hand-typed caps as an abbreviation.


  • Numbers typically should be represented by no more than 2 decimal places.
  • Stand-alone numeric values are typically aligned to the right, especially when showing decimal places. When the numeric value is paired with text, the value should follow the application locale’s text alignment practices.
  • If an application or data item does not have a defined currency type, it should be represented by the user’s local currency.
  • Numbers should use the proper separators whenever possible (e.g. 1,000 not 1000).

Presentation and overflow

  • A line’s maximum length in a paragraph should be no more than 35em long (about 35 characters).
  • All text uses a line-height of 1.4 times the size of itself (e.g. 10px font has a 14px line-height). First-level headers use a line height that is 1.25 times its size.
  • Single-line text that overflows its max-length should be condensed down into an ellipsis. Multi-line text that overflows its line should never use hyphenation to wrap words. Additionally, a set height should be determined for that multi-line text, which should also end in an ellipsis. Any condensed text must have an alternative way to review the full text that has been masked.
  • All text should be left-aligned. The exception is for buttons and links, which have center-aligned text. Never use justified text. Additionally, RTL languages use right-alignment by default.

Last updated: Mar 2019


Pega interfaces are grammatically correct, friendly, and professional. Below are a few items to consider when writing for Pega applications:

  • Use the active voice, not the passive voice.
  • Be concise. Do not use flowery language, but strive to be clear.
  • Use a positive tone. When writing error messages, do not assign or take blame.
  • Use full words instead of contractions (e.g., “do not” instead of “don’t”)
  • Avoid abbreviations and jargon.
  • When an object could be singular or plural, use the plural version for its label.
Grammar examples

Last updated: Jun 2018

Internationalization (i18n)

Markets, countries, and employees are no longer restricted to a single monolithic language or location. Planning for the various linguistic, visual and directional challenges at the beginning of a design process will put you on the road to success.

  • Design form fields, labels, messaging areas, buttons, headers, navigation, etc. to allow for a flexible amount of space and while maintaining readability in the more robust languages. (A good rule of thumb is to account for an extra 50-100% of length.)
  • Plan for bi-directional layouts as necessary to aid those more familiar with those patterns.
  • Show dates and times in the user's preferred format. More about date and time.

Last updated: May 2019