New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: Author model #3088
Comments
This is "in progress"; we can take the discussion when I'm happy about my proposal. |
Sorry about that. I interpreted "in progress" as ready to be discussed so that the draft can by shaped iteratively. Let's forget what I wrote above for now. |
/cc @digitalcraftsman @derekperkins @spf13 @moorereason The above is my take on how Hugo should unify its author handling. The author schema itself is almost identical to @derekperkins -- but with some fundamental changes in how it is wired up. Comments welcomed. |
Overall, I'm fine with the proposal.
@derekperkins already defined a list of common attributes in his initial attempt to implement this feature. I would propose that we should keep the following list so that themes can work with a standardized sets of attributes.
I like the idea. The authors files should live in Social linksWhat's actually the difference between |
The ID is the key and is expected to be (more) constant (as it is used as a "foreign key" in author definitions). So if you have:
And want to change the name to "Google+", you can do so safely without having to update all the authors. |
I agree that this is great, from #3090:
I would do this with authors, even if there were only three, and would probably move @digitalcraftsman I know that is only a draft. I would be careful of A Consideration (Maybe)My question is re:
The order of this could mean that Chomsky is the primary author with Zinn and Hitchens as co-authors OR Chomsky as primary with Zinn as co-author and Hitchens as technical reviewer, etc. Or I might add taxonomic I appreciate this may very well have zero impact on what you're considering, but I'm throwing it out there in hopes it may bring to a light a less-considered perspective. |
The USAGE or the order is contextual, i.e. theme/site. The example you're giving does not imply any order (as we have defined it). A complete example would be: Site config:
And in front matter:
Given the above:
The above may not be the way it should be, but that is what this discussion is all about. |
@bep, I think @rdwatters is proposing that the order of the authors, as defined in the content frontmatter, could be the default sort order instead of weight. I tend to agree. It would be easier and more intuitive for the content editor to simply change the order in the frontmatter than it would be to add weights. So, in your last example, you would get:
If you wanted to sort them by weight, you would do |
Background information: "Falsehoods Programmers Believe About Names". I don't think we have to worry about people who don't have names yet, but…
I strongly suspect the existence of FirstName and LastName will encourage western-european theme authors to write things like "{{person.FirstName}} {{person.LastName}}" when Hungarians will want "{{person.FamilyName}} {{person.GivenName}}" and Japanese, Chinese, and Koreans will want "{{person.FamilyName}}{{person.GivenName}}" And then there are the Indonesians with one name, and Singaporeans with double-ended names and people with multiple middle names and super-long Arabic names… Suppose Abraham Lincoln, Rubik Ernő, 홍길동, Daryl Koh Pei Xiang, Suharto, Muhammad ibn Salman ibn Ameen al-Farsi, and Stefani "Lady Gaga" Germanotta all start a group blog* and they all want their names written as I've written them here. How should almost all themes generally handle names? As far as I can tell, theme authors should strongly be encouraged by the docs to only use DisplayName, and site authors should be strongly encouraged by the docs to use only DisplayName unless they have very specific sorting problems. While it's unlikely that any given Hugo site will have names from all of these different style, any given theme has a good chance of being used by people who have names in three or more of these styles. * I was tempted to write "walk into a bar", but Github Flavored Markdown doesn't have strikethrough. Pity. |
Just a wild thought after reading @adiabatic's comment: With
If one of the authors needs a different schema, it can be overwriten in the author config.
Now using Theme Authors could then use |
@adiabatic thanks for pointing this out that cultures have different habits regarding names. @kevinburke's suggested approach looks like a very flexible solution to this problem. And it also defines a de facto standard for a template variable that should be used across all themes consistently. But when customizing the user names we've to prevent that users don't add recursion (e.g. |
Just so I can make more informed comments on this thread: are we discussing
??? And @moorereason Yes, that it what I was saying. If prioritizing convenience for content authors, it makes more sense for the author array to be an explicit ordering... |
I think it's 3. All of it is important if we want to get authors right and make themes truly portable. Given / Family / Display nameI used those first when I built the author integration and later added I had the concept of a default display name template originally. If there's a way to safely allow for a template override like @KevinGimbel suggested, I think that's a great idea. Author sorting
Common fieldsI still agree with myself from the original proposal. :)
I think we could be smart about the bio fields, either truncating the bio to N characters if the short bio is empty, or falling back on shortBio if Bio is empty. Author config locationI like the cascading approach, with the default being under What about multiple files? My original proposal used the filename as the Social linksI like having the urlTemplate by default. People are notorious for using the wrong social links, e.g. not using https, including/excluding www improperly. Out of the box, I think Hugo should scrub and fix those by default. The other implementation details look good to me. |
schema.org has honorificPrefix (Dr./Mr./Mrs.) and honorificSuffix (M.D./Ph.D/MSCSW). Adding HonorificPrefix(es) and HonorificSuffix(es) may be either a good idea or a bad idea, but I think we ought to think about them if only to conclude that they're a bad idea and/or we don't need them. |
@bep I may be wrong here, but was this proposal implemented? From what I understand it has not been, so may be I could chime in. I would personally prefer keeping things as simple as possible, which means that probably just a DisplayName could be used as suggested by @KevinGimbel. The sorting could also be initially based only on the weights, as suggested originally. This might keep this simple while thinking and may be even while implementing. I base this call for simplicity from the Keep It Simple Stupid mantra. |
This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help. |
I am commenting because of the stale label attached to the issue. I think this feature request is important. It should be tagged with the "Keep" label since no activity in another 21 days would automatically close the issue (based on .github/stale.yml). The issue number #1850 could be closed in favour of either this or #3776. This is based on my limited understanding, and could be wrong. Additionally, I would request the stale timeout to be increased to 60 days. This is based on a totally unscientific reason that between December 6 and December 27, a lot of volks would be more engaged outside, and hence may end up missing the stale to closed transition for valid issues. This may lead to many valid issues being closed and subsequent requests for reopen next year. |
This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help. |
OK, I'm probably not the only one confused: what does this implementation refer to as of now? A more useful set of questions:
As for that one, an Is there anything non-trivial, what holds back advancement on this? |
Can this be added soon? But instead of data make it flexible to configure where data of authors is stored. It can be in data or taxonomy as many sites use taxonomies for multiple authors. This data can be made available through |
I think it is not to have a model at all. Make the value be loaded from a config file, data file or taxonomy. The configuration could be as simple as:
It looks for the data file, config file or taxonomy called |
One thing I'm surprised of not seeing here is consideration of the existing standards for describing authors and/or persons, like the Dublin Core, FOAF, OpenGraph and other metadata. Sure, themes can build them from these configurations, but if some of the metadata are to be predefined, using previously agreed-upon items like those could make things more predictable and overall easier. |
My 2¢ on naming: People think of names in terms of "first name" "family name" "maiden name" etc. but for display what is really needed are various lengths of name plus the ability to sort names. The "first name" etc things are very culturally specific and can't really be done universally. There are too many traditions to try to cover them all. Instead you can say Alice's short name is "Alice", her display name is "Alice Smith", her full name is "Alice Banana Smith, IV", and she sorts as "Smith, Alice Banana 4". That also works for "Elizabeth"/"Elizabeth II"/"Queen Elizabeth the Second"/"Windsor, Elizabeth Alexandra Mary" and other cases that would be basically impossible to handle otherwise. For names from cultures with family names first, the sort name will be "Xi Jinping" and your house style determines whether the display name is shown as "Jinping Xi" or "Xi Jinping". |
Rather than limit this to simply authors, maybe a better approach would be to implement the hCard standard as documented here for persons/orgs and/or some overlay with schema.org data: The benefit being that it is standards compliant and supported by search engines. To handle social links the This could later be supplemented if more work is done on internal templates for structured data for |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Most the work I've done on Hugo lately, have been with simplicity in mind; mostly for the end users, but also to simplify future maintenance and extensions. We may have confused some with the _index.md thing, but the code cleaned up nicely (we have now only one
pageRender
method, for starters), and themultilingual
feature landed nicely.So, any work to make
authors
a first-class Hugo citizen should not be accompanied by a three pages manual.Here is my design proposal, in pseudo code.
Note that the attributes on
author
below are picked by random, and not really important to this discussion. We should agree on a set of common attributes, so they can be used in themes, butauthor
should be schema-less, i.e. a map, so if someone wants to add favourite_colour, so be it.Pseudo-coded site config:
So given the above, I see the following rule set:
Author
andAuthors
should be onPage
;Author
should be the first in a sorted list, sorted by weight etc., seemenus
.Both
author
andauthors
(a slice) should work in frontmatter. This will be theid
of the authors, e.g.bep
in the example above.author
andauthors
should also be possible to be set in site config. These will be default values for pages with no values.The author configuration can be parsed top-down: Each language can override author attributes from the global configuration, but not from siblings (
spf13
will only have a slogan in Norwegian).The configuration loading should take inspiration from the
output
andmedia
package.I guess this should even have its own package ...
people
, orauthor
?The author config should also be externalised at some point, see proposal: Optional externalize site config #3090.
Social links
I suggest we just name it
socialLinks
, so.Author.socialLinks
will give you an ordered (ordered byWeight
) list of:The SocialLinks can be defined like this:
Hugo should support a default definition of the most common, users can add or redefine in site config (see
MediaType
andOutputFormat
).The social links can then be added to a given
author
:Note the above is pseudo-code, and it should probably support both slices and a single string as placeholders.
General
We should consider casing issues in all of the above. I suggest:
.Param "author.firstNAME"
will work fine.The above is not complete, but it covers the most important aspects.
The text was updated successfully, but these errors were encountered: