use label attribute with facet strip labels

[d-morrison]

In situations when variables have label attributes, I would like to be able to use the label attributes in facet strip labels with labeller = label_both

For example, in the reprex below, I would like the facet strip labels to read "Iris Species: setosa", etc.:

library(tidyverse); library(labelled)
iris |> 
    mutate(Species = Species |> labelled::set_label_attribute("Iris Species")) |> 
    ggplot() + 
    aes(x = Sepal.Length, y = Sepal.Width) + 
    geom_point() + 
    facet_wrap(~Species, labeller = label_both)

^{Created on 2025-12-19 with reprex v2.1.1}

Session info

sessioninfo::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value
#>  version  R version 4.5.2 (2025-10-31)
#>  os       macOS Sequoia 15.7.2
#>  system   aarch64, darwin20
#>  ui       X11
#>  language (EN)
#>  collate  en_US.UTF-8
#>  ctype    en_US.UTF-8
#>  tz       America/Los_Angeles
#>  date     2025-12-19
#>  pandoc   3.6.3 @ /Applications/RStudio.app/Contents/Resources/app/quarto/bin/tools/aarch64/ (via rmarkdown)
#>  quarto   1.8.26 @ /usr/local/bin/quarto
#> 
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package      * version    date (UTC) lib source
#>  cli            3.6.5      2025-04-23 [1] CRAN (R 4.5.0)
#>  curl           7.0.0      2025-08-19 [1] CRAN (R 4.5.0)
#>  digest         0.6.39     2025-11-19 [1] CRAN (R 4.5.2)
#>  dplyr        * 1.1.4      2023-11-17 [1] CRAN (R 4.5.0)
#>  evaluate       1.0.5      2025-08-27 [1] CRAN (R 4.5.0)
#>  farver         2.1.2      2024-05-13 [1] CRAN (R 4.5.0)
#>  fastmap        1.2.0      2024-05-15 [1] CRAN (R 4.5.0)
#>  forcats      * 1.0.1      2025-09-25 [1] CRAN (R 4.5.0)
#>  fs             1.6.6      2025-04-12 [1] CRAN (R 4.5.0)
#>  generics       0.1.4      2025-05-09 [1] CRAN (R 4.5.0)
#>  ggplot2      * 4.0.1.9000 2025-12-13 [1] Github (tidyverse/ggplot2@60f5ed5)
#>  glue           1.8.0      2024-09-30 [1] CRAN (R 4.5.0)
#>  gtable         0.3.6      2024-10-25 [1] CRAN (R 4.5.0)
#>  haven          2.5.5      2025-05-30 [1] CRAN (R 4.5.0)
#>  hms            1.1.4      2025-10-17 [1] CRAN (R 4.5.0)
#>  htmltools      0.5.9      2025-12-04 [1] CRAN (R 4.5.2)
#>  knitr          1.50       2025-03-16 [1] CRAN (R 4.5.0)
#>  labeling       0.4.3      2023-08-29 [1] CRAN (R 4.5.0)
#>  labelled     * 2.16.0     2025-10-22 [1] CRAN (R 4.5.0)
#>  lifecycle      1.0.4      2023-11-07 [1] CRAN (R 4.5.0)
#>  lubridate    * 1.9.4      2024-12-08 [1] CRAN (R 4.5.0)
#>  magrittr       2.0.4      2025-09-12 [1] CRAN (R 4.5.0)
#>  pillar         1.11.1     2025-09-17 [1] CRAN (R 4.5.0)
#>  pkgconfig      2.0.3      2019-09-22 [1] CRAN (R 4.5.0)
#>  purrr        * 1.2.0      2025-11-04 [1] CRAN (R 4.5.0)
#>  R6             2.6.1      2025-02-15 [1] CRAN (R 4.5.0)
#>  RColorBrewer   1.1-3      2022-04-03 [1] CRAN (R 4.5.0)
#>  readr        * 2.1.6      2025-11-14 [1] CRAN (R 4.5.2)
#>  reprex         2.1.1      2024-07-06 [1] CRAN (R 4.5.0)
#>  rlang          1.1.6      2025-04-11 [1] CRAN (R 4.5.0)
#>  rmarkdown      2.30       2025-09-28 [1] CRAN (R 4.5.0)
#>  rstudioapi     0.17.1     2024-10-22 [1] CRAN (R 4.5.0)
#>  S7             0.2.1      2025-11-14 [1] CRAN (R 4.5.2)
#>  scales         1.4.0      2025-04-24 [1] CRAN (R 4.5.0)
#>  sessioninfo    1.2.3      2025-02-05 [1] CRAN (R 4.5.0)
#>  stringi        1.8.7      2025-03-27 [1] CRAN (R 4.5.0)
#>  stringr      * 1.6.0      2025-11-04 [1] CRAN (R 4.5.0)
#>  tibble       * 3.3.0      2025-06-08 [1] CRAN (R 4.5.0)
#>  tidyr        * 1.3.1      2024-01-24 [1] CRAN (R 4.5.0)
#>  tidyselect     1.2.1      2024-03-11 [1] CRAN (R 4.5.0)
#>  tidyverse    * 2.0.0      2023-02-22 [1] CRAN (R 4.5.0)
#>  timechange     0.3.0      2024-01-18 [1] CRAN (R 4.5.0)
#>  tzdb           0.5.0      2025-03-15 [1] CRAN (R 4.5.0)
#>  vctrs          0.6.5      2023-12-01 [1] CRAN (R 4.5.0)
#>  withr          3.0.2      2024-10-28 [1] CRAN (R 4.5.0)
#>  xfun           0.54       2025-10-30 [1] CRAN (R 4.5.0)
#>  xml2           1.5.1      2025-12-01 [1] CRAN (R 4.5.2)
#>  yaml           2.3.12     2025-12-10 [1] CRAN (R 4.5.2)
#> 
#>  [1] /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/library
#>  * ── Packages attached to the search path.
#> 
#> ──────────────────────────────────────────────────────────────────────────────

[aksh08022006]

Hi @d-morrison, thanks for raising this issue — I’m interested in working on it.

From what I understand, the goal is to allow label_both (and possibly related labellers) to make use of variable label attributes (e.g. from labelled::set_label_attribute()) when generating facet strip labels, instead of relying only on the raw variable name.

Proposed approach (please let me know if this aligns with ggplot2’s design):

Detect whether the faceting variable has a "label" attribute (or similar) attached.

If present, use that attribute as the variable name portion in label_both, so that facet strips become something like "Iris Species: setosa" instead of "Species: setosa".

Fall back to the current behavior if no label attribute exists, to preserve backward compatibility.

Keep the change scoped to labeller logic (e.g. inside the labeller() / facet label generation code), without affecting scale labels or other components.

Before I start implementing, I wanted to ask:

Is using the "label" attribute (as set by labelled) the preferred mechanism here, or should this be more generic (e.g. any variable-level label attribute)?

Would you expect this behavior to apply only to label_both, or also to label_value / label_context?

Are there any design constraints or edge cases (e.g. multi-variable faceting, non-character labels, backward compatibility concerns) I should be careful about?

Happy to put together a minimal PR once the direction is confirmed. Thanks!

[teunbrand]

Thanks for the suggestion! This kind of aligns with what we have done for variables in aes() that we take a potential label attribute when the expression is a naked column name.

Is using the "label" attribute (as set by labelled) the preferred mechanism here, or should this be more generic (e.g. any variable-level label attribute)?

I'm unsure about the distinction. Can you elaborate? In general I think when the facetting expression is just a naked column name, we may take that column's label attribute, but otherwise we preserve current behaviour.

Would you expect this behavior to apply only to label_both, or also to label_value / label_context?

Anywhere the column name of the variable is currently included. I don't know about the labeller functions well enough to advise on the specifics, I never use them myself.

Are there any design constraints or edge cases (e.g. multi-variable faceting, non-character labels, backward compatibility concerns) I should be careful about?

In case of multi-variable facetting, as long as the facetting expressions are naked column names, their label attributes ought to be included. I think the label attribute should be expected to be a character vector or expression of length 1. If that expectation is not met, the label attribute should be dismissed with a warning and current behaviour independent of the attribute should take over.