feat: add issuer specific fip validity to operator pages by MoritzWeber0 · Pull Request #684 · fipguide/fipguide.github.io

MoritzWeber0 · 2026-02-08T18:30:58Z

For each FIP issues a file called validity.yaml can be added to the corresponding operator directory, including information which how many coupons for which operator are issued. For example, let's have a look the at validity.yaml for FIP issuer DB:

_anchors:
  coupon-4fields: &coupon-4fields
    status: valid
    text:
      de: "1 Freifahrtschein mit jeweils 4 Feldern pro Jahr. Jedes Feld ist zwei Tage gültig."
      en: "1 coupon with 4 fields each per year. Each field is valid for two days."
      fr: "1 coupon avec 4 champs chacun par an. Chaque champ est valable deux jours."
  coupon-not-available: &coupon-not-available
    status: invalid
    text:
      de: "Nicht verfügbar"
      en: "Not available"
      fr: "Non disponible"
  reduced-50: &reduced-50
    status: valid
    text:
      de: "50 % Rabatt"
      en: "50 % discount"
      fr: "50 % de réduction"
pkp:
  fip-coupon: *coupon-4fields
  fip-coupon-relatives: *coupon-4fields
  fip-reduced-ticket: *reduced-50
zssk:
  fip-coupon: *coupon-4fields
  fip-coupon-relatives: *coupon-not-available
  fip-reduced-ticket: *reduced-50

Resolves #446

TODO:

netlify · 2026-02-08T18:31:49Z

✅ Deploy Preview for fipguide ready!

Name	Link
🔨 Latest commit	`dc1a37b`
🔍 Latest deploy log	https://app.netlify.com/projects/fipguide/deploys/699b06d5493778000886daf4
😎 Deploy Preview	https://deploy-preview-684--fipguide.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

MoritzWeber0 · 2026-02-08T20:50:24Z

Should be ready for review now, @lenderom @therobrob. I'll keep it in the draft state until #680 is merged as this PR is based on it and should not be merged before.

lenderom · 2026-02-09T16:01:27Z

@MoritzWeber0 Thank you for your implementation. I think this will help many of our collegues. Do you think we should implement a kind of "Default" per employer? Like usually SNCF gives 1 Coupon with 4 Fields and we only specify the deviations on the operator site?

MoritzWeber0 · 2026-02-09T16:54:44Z

@MoritzWeber0 Thank you for your implementation. I think this will help many of our collegues. Do you think we should implement a kind of "Default" per employer? Like usually SNCF gives 1 Coupon with 4 Fields and we only specify the deviations on the operator site?

I'm against an implicitly added default. We should only add explicit information if we have it, otherwise let's fall back to unknown. The only reason would be less boilerplate (the YAML section grows a bit too quickly maybe). But there are probably better solutions like defining some defaults globally and then just reference them via a one-liner.

lenderom · 2026-02-09T17:44:10Z

@MoritzWeber0 Thank you for your implementation. I think this will help many of our collegues. Do you think we should implement a kind of "Default" per employer? Like usually SNCF gives 1 Coupon with 4 Fields and we only specify the deviations on the operator site?

I'm against an implicitly added default. We should only add explicit information if we have it, otherwise let's fall back to unknown. The only reason would be less boilerplate (the YAML section grows a bit too quickly maybe). But there are probably better solutions like defining some defaults globally and then just reference them via a one-liner.

Yeah I was more thinking about the boilerplate, not a "default" information but a way to avoid writing on every page "SBB employees have 8 fields every field is valid for one day" :D
But it's not a must have. Just an idea to avoid extremly large yaml metadata :)

lenderom · 2026-02-09T17:47:17Z

Another point I was thinking about was the considerationfo things like #681

It doesn't have to be implemented in this PR, I was just thinking about covering this problem in your implementation. For example instead of having a row in the table for the FIP Coupon there could be a text like "unlimited free travel". But we could also find other ways of covering this topic :)

MoritzWeber0 · 2026-02-09T17:57:03Z

Another point I was thinking about was the considerationfo things like #681

It doesn't have to be implemented in this PR, I was just thinking about covering this problem in your implementation. For example instead of having a row in the table for the FIP Coupon there could be a text like "unlimited free travel". But we could also find other ways of covering this topic :)

This is the reason why I removed some of the structured data from the previous PR and made it more flexible with the text :)
But for #681 I would need more information about who exactly gets those free benefits. So rather a separate PR.

therobrob

I’ve just reviewed the technical parts, not the md-files.

Two further comments:

for me it seems slightly confusing showing the grey status with question marks for cases, where we don’t know the information from all operators. It suggests we have no information at all. I think this case is very common, until we don’t have the information from all operators.
Edit: why do we handle the same case ("we don’t have information from all operators") in two different ways?
One time we say "valid" and one time we say "unknown" – where’s the difference between them?

this leads me to the second aspect: the button for the dialog isn’t optimal in my opinion. It is not self-explanatory, because there is no label and there is the second status-icon to the left (two icons, two different meanings for interacting). I envision a single, comprehensive button, so the user can click the whole information.

i18n/de.yaml

therobrob · 2026-02-09T18:14:26Z

layouts/partials/fip-validity.html

+</div>
+
+{{- if not .disable_dialog -}}
+  {{- partial "dialog" (


I prefer not to color the button. Dark green and grey is okay, but red looks rather than an error than an interactive element.

therobrob · 2026-02-09T18:16:03Z

layouts/partials/fip-validity-dialog.html

+  <thead>
+    <tr>
+      <th>{{ T "fipValidity.issuer" }}</th>
+      <th>{{ T "trainCategory.additionalInformation" }}</th>


mhm it isn’t just "additional information" but the information itself :D
what do you think of "validity" or "acceptance"?

I think neither "Validity" or "Acceptance" is the correct term if we talk about the number of issued coupons for example. I called it "rules" now and added it it's own translation key. We can talk about the name again, not 100% happy with rules as it sounds so strict, but in the end it is.

Maybe I was just too lazy too create a new translation key when I created the PR, so I used an existing one :D

therobrob · 2026-02-09T18:19:21Z

layouts/partials/fip-validity-dialog.html

+      {{- $statusIcon := index $iconMapping $status -}}
+      <tr>
+        <td>
+          {{ partial "link" (dict "Destination" (print "/operator/" .File.ContentBaseName) "Text" .Title "Page" $.page) }}


do we need the link here? The usecase fot the dialog is to look up the rules for my own operator and i don’t need the fip information about my own operator, do i?

In general true, but also it doesn't hurt, or? Maybe there is a use-case that we don't see. I can also remove it though.

MoritzWeber0 · 2026-02-22T12:48:15Z

Yeah I was more thinking about the boilerplate, not a "default" information but a way to avoid writing on every page "SBB employees have 8 fields every field is valid for one day" :D But it's not a must have. Just an idea to avoid extremly large yaml metadata :)

I changed the implementation to use a validity.yaml per FIP issuer. This has a few advantages:

We can use YAML anchors to reuse texts, this reduces the amount of duplicated content, making it easier to maintain it in the future.
The information is now reversed in comparison to the previous implementation. We collect the information per FIP issues in one a file. This represents how we get the information.
We don't have to define the validity multiple times for the different languages, only the text is still localized.
The frontmatter remains unchanged and we don't have to scroll endlessly to get to the operators content.

MoritzWeber0 mentioned this pull request Feb 8, 2026

feat: Render FIP validity from params #477

Closed

MoritzWeber0 requested review from lenderom and therobrob February 8, 2026 20:50

therobrob reviewed Feb 9, 2026

View reviewed changes

MoritzWeber0 force-pushed the feat/add-dialogs branch 3 times, most recently from 1b5a622 to ea75e56 Compare February 10, 2026 08:02

MoritzWeber0 force-pushed the feat/fip-validity branch from ee54aeb to d738373 Compare February 14, 2026 14:19

MoritzWeber0 mentioned this pull request Feb 21, 2026

Issue with operator ÖBB #694

Open

This was linked to issues Feb 21, 2026

Issue with operator ÖBB #694

Open

Number of FIP Coupons and Reduction #446

Open

MoritzWeber0 added 12 commits February 21, 2026 22:39

feat: add issuer specific fip validity to operator pages

cda2a6d

feat: use cancel icon

62127a8

refactor: transform to fip-validity shortcodes

0bc47c0

fix: handle renfe and euskotren

ee72ff8

fix: add missing translation key

d279e54

feat: Add Deutsche Bahn FIP validity

5c46947

fix: change all "fip-coupon-relatives" to unknown

35788af

feat: Add FIP validity for SNCF employees

2e51211

feat: align db information to the existing style

38b6a9d

feat: add information for gb employees

0c1cd07

fix: Unify fip relatives text for db

03d5221

fix: hide current operator from table

75f04ae

MoritzWeber0 added 3 commits February 21, 2026 22:39

feat: update archetypes

e79b302

fix: Rename "FIP Freifahrt Angehörige"

488c43c

feat: Use larger buttons for fip validity

323d131

MoritzWeber0 force-pushed the feat/fip-validity branch from 6fba426 to 323d131 Compare February 21, 2026 21:39

feat: Replace Params with validity.yaml

db1cacc

MoritzWeber0 added 4 commits February 22, 2026 13:52

feat: Add missing operators for DB validity

a6ba438

feat: Add missing operators for GB FIP issuer validity

4f8c9e2

refactor: Move existing validity.yaml to anchors

11ab9d1

feat: Support markdown in fip validity texts

dc1a37b

Uh oh!

Comments

Conversation

MoritzWeber0 commented Feb 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

netlify bot commented Feb 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for fipguide ready!

Uh oh!

MoritzWeber0 commented Feb 8, 2026

Uh oh!

lenderom commented Feb 9, 2026

Uh oh!

MoritzWeber0 commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lenderom commented Feb 9, 2026

Uh oh!

lenderom commented Feb 9, 2026

Uh oh!

MoritzWeber0 commented Feb 9, 2026

Uh oh!

therobrob left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

therobrob Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

therobrob Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

MoritzWeber0 Feb 21, 2026

Choose a reason for hiding this comment

Uh oh!

therobrob Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

MoritzWeber0 Feb 21, 2026

Choose a reason for hiding this comment

Uh oh!

MoritzWeber0 commented Feb 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

MoritzWeber0 commented Feb 8, 2026 •

edited

Loading

netlify bot commented Feb 8, 2026 •

edited

Loading

MoritzWeber0 commented Feb 9, 2026 •

edited

Loading

therobrob left a comment •

edited

Loading

therobrob Feb 9, 2026 •

edited

Loading