You shouldn't use Dictionary entries for this type of content. Dictionary phrase is versioned field which means you need to copy these values for every single language and when it is changed, you need to change it everywhere (applies when you don't have language fallback in place).

You have four options:

1. Having these values hard coded in code in some static .cs files as constants - IMHO not recommended option as changing means code change and deployment
2. Having these link value in config files as elements so they are easily changeable via config entries - be honest - how often these paths will be changed? - good option as it doesn't involve big overhead and no deployment is needed, however content editors and devops need to be aligned when the new content is published so at the same time also configs are changed -> this option however means restart of web app when config is changed
3. Having template with broad list of Link field type fields on Site level where content editors need to specify new path to that particular functionality -> Good option but needs involvement from content editors and it has additional step for them. Also publishing is needed.
4. Looking up pages based on template type. You will use SOLR to find pages based on specific template. The most content editor friendly (no additional work for them) and no devops involvement -> IMHO best option.

You shouldn't use Dictionary entries for this type of content. Dictionary phrase is versioned field which means you need to copy these values for every single language, and when it is changed you need to change it everywhere (applies when you don't have language fallback in place).

You have four options:

1. Having these values hard coded in code in some static .cs files as constants - IMHO not recommended option as changing means code change and deployment
2. Having these link value in config files as elements so they are easily changeable via config entries - be honest - how often these paths will be changed? - good option as it doesn't involve big overhead and no deployment is needed, however content editors and devops need to be aligned when the new content is published so at the same time also configs are changed -> this option however means restart of web app when config is changed
3. Having template with broad list of Link field type fields on Site level where content editors need to specify new path to that particular functionality -> Good option but needs involvement from content editors and it has additional step for them. Also publishing is needed.
4. Looking up pages based on template type. You will use SOLR to find pages based on specific template. The most content editor friendly (no additional work for them) and no devops involvement -> IMHO best option.