Aliases are currently implemented as described here: if you type [mice]([[mouse]]) then the link is rendered as [[mice]]. All this does is make the link text render with brackets rather than color (or other style marker). To me, this misses the problem that aliases are needed to solve. It actually gets things backwards - it requires typing a lot rather than reducing the typing required.
The problem that must be solved is this: in different contexts, you want different text strings to refer to the same concept or link to the same page. You don’t want one page for mouse and one for mice or for muis (or whatever “mouse” is in your language). You want all the info in one place.
You could link to one place by always linking with [[mouse]] and never “mice” or “muis”, but this causes two problems: 1) Sometimes you want to use different text than the linked page title due to writing in multiple languages or due to grammar needs, but you can’t do that and also use the simple double-bracket link syntax. You must manually type a complex link with different display text like [mice]([[mouse]]). That’s a lot of extra keystrokes. 2) The unlinked references for mouse currently shows only hits for “mouse” and not for “mice” or “muis”, but it should link to all text strings that refer to that same concept.
Proposed solution: create a property or category for frontmatter that lets you define synonyms (i.e. aliases) for a page term (say the page mouse) with something like Aliases: mice, muis. Then, any text string on that line is used in two ways. 1) any instance of [[mice]] is interpreted as [mice]([[mouse]]) so you can quickly type the link and have it go to the correct place. 2) the unlinked references page for mouse would also show unlinked hits for mice and muis.
Aliases are fundamentally synonyms, but currently what Logseq is calling aliases is just a very small style change without any of the functionality the user would expect of synonyms. Comments welcome!
Actually, there’s alias support. Check https://logseq.github.io/page/Page%20Alias.
But aliases only support linked references for the record, we’ll add the support for unlinked references later.
When you say that there is alias support, what does that mean exactly? The page you linked has no explanation and logseq doesn’t currently act the way that I describe, even for the (1) part of my explanation. Maybe aliases have a well-defined function in org-mode, but I’m not familiar with it.
It looks to me as if when you add alias: mice to the page mouse, it creates the page mice with the property alias: mouse. Is that the intended function? Does it work differently for you? That is not what aliases should do in my opinion, for the reasons discussed above. Thanks.
Currently, logseq doesn’t redirect to the specified alias page because we haven’t figure out what’s the best solution. For example, we have three pages “A”, “B”, “C”, page “A” has an alias of page “B”, and page “B” has an alias of page “C”.
The problem here is which page should it redirects to when you click the page [[C]], page “B” or page “A”?
What if page “C” has an alias of page “A”? It’ll be a loop.
What logseq does support is that if you specified page “A” has both aliases of “B” and “C”, all the blocks which referenced any of the page A|B|C will be displayed on all the three pages.
Aliases example for markdown users:
---
title: A
alias: [[B]], [[C]]
---
I record a gif demo to show what logseq does for the record:
You are still thinking of aliases according to some logic that is not matching what I am suggesting, and the explanation you are giving is not making it totally clear. The .gif is also still not clear to me. I think that you have implemented aliases currently so that when “A” is given alias “B”, logseq creates a page for “B” that is automatically given alias “A”, so they are mathematically symmetric. But the goal is not to have a bunch of pages that all are equal. The goal is to allow users to use different text strings to all refer to the same page. There is the base page, “A”, and it has aliases B and C. B and C should not be pages with aliases to A. B and C should just be references somewhere in the database so that any links to B and C redirect to page A. Then you will not have any problems with looped references.
Read my first post proposed solution again. I am not saying that adding alias: mice to page “mouse” should create a page for “mice” that has an alias for “mouse”. Instead, alias: mice should create some link reference so that if a user types [[mice]] on some page, that is parsed as [mice]([[mouse]]).
You said that you haven’t implemented redirects because you don’t know the best solution. I am saying that this proposal–eliminating the current behavior that creates alias pages and replacing it with what I am proposing–is the best solution.
You might wonder what to do if the user has page “mouse” with an alias to “mice” and then tries to create a page for “mice”. Answer: tell the user that “mice” is currently being used as an alias and that they cannot create a page with the same name as an alias. They must remove the alias to create the page or choose a different name.
Yes, my understanding of aliases is not exactly matched with your suggestion. Several members asked for aliases or synonyms to redirect to other pages (we enabled the [label-as-alias](page) syntax support for this too), others include me want to have equal pages so that blocks that referenced those aliases will be listed on the page too, like what you said, they are mathematically symmetric for displaying linked and unlinked references, but they can still be different files.
So, to meet both requirements we treat alias as pages because it’s the most intuitive way IMO, it might be wrong, any suggestions are welcome.
You said that you haven’t implemented redirects because you don’t know the best solution. I am saying that this proposal–eliminating the current behavior that creates alias pages and replacing it with what I am proposing–is the best solution.
As I said above, It can’t meet both requirements. Another question is, what if both page “A” and page “B” have the same alias “C”, which page should “[[C]]” be redirected to?
We can avoid this and the loop finding aliases by redirecting the alias reference to the first page which defined this alias.
Side note : Aside from page properties alias-ing, we could improve links alias-ing (display name =/= actual link)
currently, writing: [alias](page) without the double brackets around page works to display an alias , but it doesn’t provide autocompletion of filenames, same goes for /links.
maybe supporting [[alias|link]] format would helo
Regarding page alias-ing, here’s a link with interesting thoughts
If I understand you, some people want aliases as redirects, and others want aliases to be equal linked pages. You said that the current system is the only way to meet both requirements, but (unless I misunderstand) it doesn’t meet both requirements–it only meets the 2nd one. It has equal pages but no redirects, because if you have equal pages then redirects creates a potential looping problem. So people who want equal linked pages have what you are calling “aliases”, which is multiple pages that are semi-automatically linked, and whose content appears on all of the pages (I don’t know if it is duplicated or just referenced on all of them), but people who want redirects to one page do not have that. Is that right or wrong?
For a community-driven system, you will always have people who want different things and who find different things intuitive. The question should be not what seems most intuitive just in terms of the end implementation, but which solution best meets a clearly expressed need with the fewest drawbacks. So my question is: what is the need that you think the equal-page system is meeting, and is it the best system to meet that need? I attempted to clearly express the need I think aliases solve in my top post:
So first we should make sure that we agree that this is the problem we are trying to solve. If it isn’t, let me know. But assume it is. I think the current Logseq alias system doesn’t solve this problem. You said:
What problem does this solve? The problem to be solved is that I want to refer to the same information using different linking terms. But when I make “mice” an alias of “mouse”, the “mice” page doesn’t show all of the blocks on the “mouse” page. I want all of the information about that concept in one place. I should be able to click on [[mouse]] or [[mice]] and see the same information–whether on the same page (redirect) or through equal pages that sync all of the blocks between pages.
Truthfully, since the .gif doesn’t use real pages with actual content, I’m not understanding why the current system is useful. Now, regardless of the current system, there are actually two ways to use different text to refer to the same set of info:
different terms redirect to one page
different terms each have their own page with the same information duplicated on each page and all edits to any page propagated through the other alias pages
Here are some reasons that I think (1) is preferable to (2), especially for databases that have lots of aliases:
duplicates can contaminate results for anything where you want a representation of the actual non-duplicated data, such as graph visualizations, queries or other data functions, word count, etc.
any edits to blocks must be propagated through all alias pages, which might create problems (I’m thinking here especially of cases where we have transcluded blocks in other pages)
Reasons that (2) might be preferable to (1):
easier to implement, because you don’t have to check for alias conflicts
Are there other reasons that (2) is better?
You asked: “Another question is, what if both page “A” and page “B” have the same alias “C”, which page should “[[C]]” be redirected to?”
Just like Logseq would need to check that a new page title isn’t an existing alias, it would need to check that aliases for new pages are not already aliases for existing pages. It could automatically replace the alias so that if page A has alias C, and you create a new page B with alias C, then B is added as an alias for A.
This explanation is not clear to me. How does it relate to what I have outlined above? And is this in the roadmap?
Sorry, it’s too late, I’ll reply with more details tomorrow, you can give the aliases feature another test on logseq.com, the aliases references should redirect to the “target” page now.
But when I make “mice” an alias of “mouse”, the “mice” page doesn’t show all of the blocks on the “mouse” page.
@tienson, thanks for the quick fix. It’s still not working 100% as I expected. When I click a “mouse” link on most pages, it redirects to the page “mouse” (expected). But on page “mouse”, alias: mice shows mice as a clickable link and clicking it takes me to a page, “mice” with no content other than an alias: mouse block.
Should mice be clickable there? If it’s there because it’s easier to implement aliases when that page exists, perhaps have an indicator that it is an alias page and/or prevent people from adding content to those pages. When I added text to a block on page “mice”, it seemed to create a file “mice.md”, but the content there is not shown on the “mouse” page. I think that ideally the user should not be able to add content to the “mice” page.
I agree with cannibalox that having aliases suggested in page autocomplete would be a great next step after they are working well.
As always, I am a user and not a programmer, so let me know if my suggestions are ignoring technical limits.
Should mice be clickable there? If it’s there because it’s easier to implement aliases when that page exists, perhaps have an indicator that it is an alias page and/or prevent people from adding content to those pages.
I think it depends on how you use aliases, if you just need several different aliases which link to the source page, it shouldn’t be clickable. But, if the aliases have their own contents, it needs to be clickable. For example, I have a page written in English and a translated one in Chinese, I don’t want to mix the Chinese content in the source page. Another use case might be when you need to include or reference to other people’ pages.
When I added text to a block on page “mice”, it seemed to create a file “mice.md”, but the content there is not shown on the “mouse” page.
The content (blocks) will be listed in the linked references section, we can’t automatically update the mouse page when you add a block on page mice because those pages are equal in their names but not always in their contents.
I agree with cannibalox that having aliases suggested in page autocomplete would be a great next step after they are working well.
Totall agree! @cannibalox any ideas on the UX? Listing the aliases under the top matched page?
As always, I am a user and not a programmer, so let me know if my suggestions are ignoring technical limits.
I don’t think there’re technical limits, it really depends on how you use aliases, we can only warn when users want to insert any blocks to the alias page using logseq, but if people use other editors to edit the markdown/org file, it’s still a problem. I think we can add a configuration option alias/disable-link-in-source-page? so that the aliases will not be clickable in the source page, what do you think?
I think that you are using the word “aliases” differently than me and others, such as the Obsidian team, and that’s fine, but can you identify the problem that your concept aims to solve? You are thinking in terms of translating page content (blocks), but the core issue aliases are meant to solve is translation among links to the same content, not links between pages with differing but related content.
Aliases are (or should be, I think) different terms that refer to the same content (for Obsidian, the same file, for Logseq, the same page). A translation is not the same as the original. It is different content. Aliases are not the right way to solve the problem of linking related but different content in different languages. Aliases are the right way to solve the problem of linking to the same content using different names.
Thus, it does not make sense to me to say that aliases can “have their own contents”. If you have two pages with different content, e.g. one in English and one in Chinese, then those are different pages. They should not automatically redirect to each other and links to one should not automatically link to the other. If two pages have different content, then there is no “source page”. Each page is its own source.
You say that “mouse” and “mice” are equal in their names but not always in their contents. Stepping back from the current way you are thinking about the issue, does it really make sense to have 2 pages with different content but names that are considered equal? What is the problem that such a system is aiming to solve?
Different content should have different page names, full stop. There already many ways to link pages with different content, even if it is similar or just a translation. Link the English page and the Chinese page with regular links, create a page that embeds the two source pages, or run a query. But there is no other no other convenient way I know to link to the same content with different names other than aliases as I described them.
I’ll respond to the other questions once we get this issue more settled.
Thus, it does not make sense to me to say that aliases can “have their own contents”.
I’m not saying that aliases pages must have their own contents, but there’re situations that could be resulted in. E.g. when you have a page alias called A and now you need to refer to other people’ pages (those could be from a team’s repo) and there’s a page A too. The blocks of both pages will be listed in the page “A”, I’m using this a lot with several of my friends, because we can share our opinions on some topics, but we don’t have to use the same words or have to use the same language.
If you have two pages with different content, e.g. one in English and one in Chinese, then those are different pages. They should not automatically redirect to each other and links to one should not automatically link to the other.
I can’t agree on this, for example, the Chinese word for “apple” is “苹果”, I definitely want all the blocks which referenced “apple” to be listed on the page “苹果”, people can use aliases in their own way, you don’t have to add “苹果” as an alias to “apple”, but we keep the flexibility if it’s needed.
If two pages have different content, then there is no “source page”. Each page is its own source.
It depends on how the user add the aliases, if the user adds “苹果” as an alias on “apple”, then “apple” is the source page, but if the user adds “apple” as an alias on “苹果”, then “苹果” is the source page.
Link the English page and the Chinese page with regular links, create a page that embeds the two source pages, or run a query. But there is no other no other convenient way I know to link to the same content with different names other than aliases as I described them.
Yeah, I agree on this. But it’s cumbersome to create a united page every time, it’s really a pain for people whose native language is not English.
Logseq is a tool, it’s great to follow some best practices, but we don’t want to be that rigid like you shouldn’t use the aliases for something.
I’d like to be able to just set up a string of aliases such as that suggested {humility | Humility | humble and any translations in other languages) and then just click on the particular form of the word I want.
Bringing in the idea of group graphs complicates things, I think. There are a million ways that groups might work together, and it will create all kinds of issues with versioning, page title conflicts, etc. that may or may not have to do with aliases. I think it makes more sense to settle this concept for a single-user graph first and then adapt.
The issue is not whether you should be using aliases for something or not, the issue is what does the concept of aliases mean. IMO, the current system is not an alias system. It is something else, because it doesn’t do all and only what I described in my first post. You are using the term “alias” to mean something that is not what I mean, and it is not clear to me exactly what functionality defines an alias system for you. Importantly, the current system is not something that is more flexible in comparison to my proposal. It is just different. It allows and disallows different things than the system I’m proposing. What I am not understanding is what you think you are gaining with the current “separate pages” system.
Let me clarify a few terms. Say a page has: (1) the page name or title, (2) frontmatter, (3) what I am calling the page “content”, by which I mean all content except for the page title and frontmatter. Maybe you would prefer that I call (3) page text or page blocks. And call the system I’m proposing a “single page” system (one page, multiple aliases that link to that page) and your system / the current system a “separate page” system (each alias has its own page, but aliases link to each other and have some other functionality that is still not clear to me).
You write:
Here we are in agreement, and my proposal would do this. Call “mouse” the source page and “mice” the alias. In my system and your system (I think), all mentions of either “mouse” or “mice” would show up as either linked or unlinked references on page “mouse”.
What I don’t want is for content from “mouse” and “mice” to differ. Do you? If so, why? Why would you want to have content on page “苹果” that is not on page “apple” and vice-versa? If “apple” and “苹果” are literally the same concept for you, then put the content relating to them on one page. If they are slightly different concepts, have 2 pages and link them. You can connect the information related to those terms easily using page embeds, queries, or regular links.
You wrote:
I don’t see why single page is more cumbersome than separate page. With a single page system, you are not creating a united page every time. You are just creating a page and very occasionally adding an alias to that page when you realize that you want to link to it with “mice” instead of “mouse”. The page will still show unlinked references to “mice” on the page “mouse”. I understand that maybe you already have some separate pages that you will need to consolidate. That’s a one-time thing, I think. In the future, if you have a page “apple” when you are typing in Chinese and write “苹果” you will think to link it to the existing apple page and will add the alias, just as I will when writing “mice” and realizing that I want to link to page “mouse”.
In contrast, in a separate page system, I cannot trust that the content from page “mice” matches the content on page “mouse” and I will need to repeatedly check which is the “main” page when linking and manually sync page content over and over when working with older notes to make sure I’m not missing anything. Do you really want to be reading back and forth between pages “苹果” and “apple” in 2 years when you go back to them to see if there was any important info in “apple” that’s not in "“苹果” ? That’s what separate pages will force. It might not seem like a big deal now, but when you are building a lifetime notetaking system and start visiting notes months or years after the fact, it will become a nightmare.
BOTH systems will have all blocks that reference “apple” listed on the page “苹果” (or vice-versa), the only difference is that your way has these 2 terms as separate pages and my way has them as one combined page. Something is lost by keeping these as 2 separate pages, but what are you gaining by keeping these as separate rather than one page?
You are saying that people can use aliases in their own way, but the current system is not letting people use it in their own way, because it prevents me from using the term “mice” to link to the content on page “mouse”. I know that, in your mind, your way is more flexible because you are currently using it to do something that my proposed system would not let you do. There are many other ways to do what you are currently trying to do, but you are using one that might be changed. So you think your way offers additional functionality. But it actually offers different functionality, not additional functionality, and is thus not more flexible. It is just different. It does not provide the functionality of giving users the ability to easily refer to the same page with different names, which is the problem that I think most people are looking to solve with aliases.
The productivists post you put up, like me and Obsidian, speaks of aliases as “page title synonyms” - meaning the page content is the same, and only the links to page titles differ. The single page system addresses all of the concerns listed in those posts.
Could you explain this more? If you create an alias of “mice” for page “mouse”, [[mice]] will be redirected to mouse. And all the blocks which referred to mice will be listed on the page “mouse”. You can test it on logseq’s website.
Perhaps I should have said: it prevents me from using “mice” and “mouse” to both link to the same page with identical content, and creates a situation where a certain page can have content that will be later hidden by a redirect. If I am taking notes on page “mice” after pulling the page up directly in search, and then a year later wikilink [[mice]], I will be redirected to “mouse” and I won’t see the content on page “mice.”
I think we all agree that aliases are for synonyms. The difference is that we have different opinions on whether there should be only a page (the source) with content and other aliases pages should not have content.
… what does the concept of aliases mean
To me, aliases are different names pointing to something(s).
They don’t have to be page titles, a block can have aliases, all the things have names can have aliases.
The something doesn’t have to be physically equal (same content, byte to byte), as long as if they share the same concept. As the quote said:
If it walks like a duck and it quacks like a duck , then it must be a duck
I’ll not call the current system a “separate page” system, it’s a “single page” as long as if you don’t add blocks to the alias page. But it’s ok if you need to add some content to the alias page.
IMO, the current system is not an alias system. It is something else, because it doesn’t do all and only what I described in my first post. You are using the term “alias” to mean something that is not what I mean, and it is not clear to me exactly what functionality defines an alias system for you. Importantly, the current system is not something that is more flexible in comparison to my proposal. It is just different. It allows and disallows different things than the system I’m proposing. What I am not understanding is what you think you are gaining with the current “separate pages” system.
Here is your proposed solution:
any instance of [[mice]] is interpreted as [mice]([[mouse]]) so you can quickly type the link and have it go to the correct place.
It’s the current behavior on logseq.com if you defined mice as an alise of mouse, otherwise, I’ll fix it soon since it’s a bug
The unlinked references for mouse currently shows only hits for “mouse” and not for “mice” or “muis”, but it should link to all text strings that refer to that same concept.
This will be supported but not now because we need to improve the overall search performance first.
What I don’t want is for content from “mouse” and “mice” to differ. Do you? If so, why? Why would you want to have content on page “苹果” that is not on page “apple” and vice-versa? If “apple” and “苹果” are literally the same concept for you, then put the content relating to them on one page. If they are slightly different concepts, have 2 pages and link them. You can connect the information related to those terms easily using page embeds, queries, or regular links.
I might go with the “one page” way if we have a perfect tool that can automatically filter the blocks by their languages (English, Chinese, etc), Block versions might be useful.
Do you really want to be reading back and forth between pages “苹果” and “apple” in 2 years when you go back to them to see if there was any important info in “apple” that’s not in "“苹果” ? That’s what separate pages will force. It might not seem like a big deal now, but when you are building a lifetime notetaking system and start visiting notes months or years after the fact, it will become a nightmare.
Good point! I don’t think of those notes as files, they are just blocks, I don’t have to read back and force between the source page and aliases (if the alias page have some content, but it doesn’t have to), because all the content of the aliases and the source page will be listed on all the related pages. The issue here is how to sort them.
You should still see all the content of page “mice” on page “mouse” and all of its aliases pages. Otherwise, it’s a bug.
As said above, I know it might be trouble for people who don’t need the flexibility to have multiple aliases with their own content, that’s why I suggest that we can add a configuration option alias/disable-link-in-source-page?.
