feat: more specific language fields

[maelle]

Fix #15

[maelle]

@joelnitta would you mind having a look?

Now the problem is that part of the, say, Japanese fields will be under babelquarto: (the author, title, description) whereas part of them will be under babelquarto-ja:

I prefer babelquarto-ja to say babelquarto: languages: ja because it's already a pain to add one level of indentation to all the fields one is replacing.

[joelnitta]

@maelle can you merge the latest changes from main into this branch? It doesn't have the fix to #21.

[joelnitta]

Now the problem is that part of the, say, Japanese fields will be under babelquarto: (the author, title, description) whereas part of them will be under babelquarto-ja:

I agree this could be confusing. I think it would be better to only put unique fields that only apply to babelquarto under babelquarto:, like languagecodes, mainlanguage, and languages. Others I think should go under (for example), babelquarto-ja:.

I tried this out with the following. It works for giscus, but not the navbar:

babelquarto-ja:
  format:
    html:
      comments:
        giscus:
          language: ja
  website:
    navbar:
      right:
        - href: talks.qmd
          text: 発表

[maelle]

bug expected

navbar <- list(
  list(href = "bla.qmd", text = "bla"),
  list(href = "blop.qmd", text = "blop")
)

new_list <- list(
  list(href = "about.qmd", text = "about")
)

utils::modifyList(navbar, new_list)
#> [[1]]
#> [[1]]$href
#> [1] "bla.qmd"
#> 
#> [[1]]$text
#> [1] "bla"
#> 
#> 
#> [[2]]
#> [[2]]$href
#> [1] "blop.qmd"
#> 
#> [[2]]$text
#> [1] "blop"

^{Created on 2023-09-29 with reprex v2.0.2}

Maybe I could special case the navbar. :thinking:

[maelle]

utils::modifyList() seems to only work for things that have names. Maybe there's a way to write the YAML to make both Quarto and utils::modifyList() happy :thinking:

[joelnitta]

This does seem tough... there is probably a good reason purrr::list_assign() only modifies lists where all elements have names, or are all unnamed.

[joelnitta]

I've got another idea: what if there is a _quarto.<lang>.yml (for example, _quarto.fr.yml, _quarto.ja.yml, etc) that could be used in place of _quarto.yml for a particular language - so, basically treating .yml files the same way as .qmd files? There are other places as well where .yml files are used (for example. _metadata.yml to override settings within a folder), so I think this would be a good general solution. There would be some redundancy in settings between the main language and additional language yml files, but that is just what happens with a simple file replacement scheme (and this is the case anyways for qmd files, especially settings that don't change in the frontmatter).

If this method is used, the only difference between _quarto.yml and _quarto.<lang>.yml in content (besides the translations themselves) would be that _quarto.yml includes the babelquarto field with languagecodes, mainlanguage, and languages, whereas _quarto.<lang>.yml lacks this.

_quarto.yml:

project:
  type: website

website:
  title: "Joel Nitta"
  navbar:
    background: primary
    right:
      - href: publications.qmd
      - href: software.qmd
      - href: blog.qmd
      - href: talks.qmd
      - href: content/pdf/Nitta_CV.pdf
        text: "CV"

babelquarto:
  languagecodes:
  - name: ja
    text: "日本語"
  - name: en
    text: "English"
  mainlanguage: 'en'
  languages: ['ja']

_quarto.ja.yml:

project:
  type: website

website:
  title: "ニッタ ジョエル"
  navbar:
    background: primary
    right:
      - href: publications.qmd
      - href: software.qmd
      - href: blog.qmd
      - href: talks.qmd
        text: 発表 
      - href: content/pdf/Nitta_CV.pdf
        text: 履歴

[maelle]

. There would be some redundancy in settings between the main language and additional language yml files, but that is just what happens with a simple file replacement scheme (and this is the case anyways for qmd files, especially settings that don't change in the frontmatter).

Or babelquarto could use the default configuration and amend it using each language specification, so that one doesn't need to repeat anything? :thinking:

[joelnitta]

Or babelquarto could use the default configuration and amend it using each language specification

Sorry, I don't understand how that differs from what you already have? (various fields under babelquarto: that over-write the normal ones in _quarto.yml). Wouldn't we still have the same problem of needing to identify unnamed list elements?

[maelle]

I think in all cases I'll need to write my homemade version of modifyList() :grin:

[maelle]

I hope to get back to this next week! First I'll make it work as is then switch to the structure you suggested but I really don't want users to have to duplicate fields.

[joelnitta]

@maelle If you can come up with a version of modifylist() that works even for un-named elements, by all means that sounds fine. No need to implement my suggestion of _quarto.<lang>.yml files.

[maelle]

should be solved with Quarto project profiles, not homegrown code.