Lorem Ipsum cho mock UI | Độ dài tiếng Việt vs Latin khi test layout【2026】

Mock Figma đẹp — ba dòng Latin đều nhau, card không tràn, stakeholder gật đầu. Dev gắn API thật: tên sản phẩm “Gói đăng ký doanh nghiệp không giới hạn người dùng”, nút “Tiếp tục thanh toán”, badge “Đang xử lý”. Đột nhiên ellipsis xuất hiện, nút đẩy giá xuống hàng, header mobile cao thêm 40px.

Đó không phải lỗi CSS “bất ngờ”. Đó là hệ quả của việc test layout bằng phân bố độ dài Latin, rồi ship sản phẩm tiếng Việt.

Bài này dành cho designer, frontend và freelancer outsourcing ở Việt Nam — người hay dùng Lorem Ipsum cho mock UI nhưng cần tránh vỡ layout khi nội dung thật là tiếng Việt có dấu.

Bài viết này giúp bạn

• Hiểu Lorem Ipsum dùng đúng giai đoạn nào trong mock
• So sánh độ dài / mật độ Latin vs tiếng Việt bằng bảng và ví dụ cụ thể
• Có fixture ngắn–dài–worst-case để nhét vào Storybook hoặc Figma
• Biết component nào vỡ sớm nhất khi đổi ngôn ngữ
• Tạo dummy nhanh bằng công cụ Lorem Ipsum (trình duyệt, không đăng ký)

---

Lorem Ipsum là gì — và không phải là gì

Lorem Ipsum là dummy text dạng Latin (bắt nguồn từ Cicero, từ đã xáo trộn). Mục đích cổ điển: lấp khối chữ để người xem không đọc nội dung, chỉ nhìn bố cục, font và khoảng trắng.

Phù hợp

• Wireframe sớm — chưa có copy strategy
• Kiểm tra mật độ đoạn văn trên landing / blog layout
• Tránh screenshot chứa joke placeholder kiểu “Your face here”

Không đủ để

• Ký duyệt UI production cho app/site tiếng Việt
• Chứng minh truncation, wrap, line-clamp hoạt động đúng
• Test font metrics với dấu thanh (ố, ể, ự, ẵ…)
• Mô phỏng nhãn UI ngắn và “đanh” (nút, chip, breadcrumb)

Sinh đoạn nhanh khi cần khối filler: mở Lorem Ipsum Generator, chọn số đoạn và số câu mỗi đoạn, sao chép vào Figma hoặc HTML. Sau đó thay bằng fixture tiếng Việt trước khi gọi mock là “content-complete”.

---

Vì sao Latin “ổn” rồi tiếng Việt lại vỡ

Ba khác biệt thực tế giữa dummy Latin và copy tiếng Việt:

1. Phân bố độ dài từ

Latin placeholder hay dùng từ 4–8 ký tự, nhịp đều. Tiếng Việt ghép nhiều từ đơn thành cụm nghĩa dài:

Vai trò UI	Latin / EN ngắn	Tiếng Việt thường gặp
Nút CTA	Submit / Buy	Đăng ký ngay / Tiếp tục thanh toán
Tiêu đề card	Organic milk	Sữa tươi hữu cơ nguyên kem 1 lít
Badge trạng thái	Done	Đã hoàn tất / Đang chờ xác nhận
Empty state	No data	Chưa có dữ liệu để hiển thị

Cùng một max-width: 160px, Latin vừa khít — tiếng Việt tràn hoặc bị cắt giữa từ.

2. Dấu thanh và chiều cao dòng

Glyph có dấu (ậ, ữ, ợ…) chiếm không gian vertical hơn chữ Latin phẳng. Font + line-height thiết kế sát trên Lorem dễ chạm cạnh hoặc cắt dấu trên mobile. Đây là lỗi typography hay bị bỏ qua vì mock Latin “trông sạch”.

3. Mật độ thông tin khác

Đoạn Lorem 5 câu có nhịp đọc giả. Copy marketing tiếng Việt thường ngắn hơn ở hero (“Một câu”) hoặc dài hơn ở mô tả pháp lý. Layout chỉ đẹp khi có đúng 3 đoạn Lorem sẽ xẹp khi launch chỉ còn một dòng headline.

---

Số liệu nhanh: cùng “ý nghĩa”, khác độ dài

Ví dụ so sánh ký tự (không tính khoảng trắng thừa), đủ để thấy gap:

EN:  "Continue to payment"           → 20 chars
VI:  "Tiếp tục thanh toán"           → 19 chars (nhưng rộng hơn với font nhiều UI)

EN:  "Unlimited seats plan"          → 19 chars
VI:  "Gói không giới hạn người dùng" → 29 chars

EN:  "Processing"                    → 10 chars
VI:  "Đang xử lý yêu cầu của bạn"    → 26 chars

Nhãn VI không luôn dài hơn từng ký tự ASCII — nhưng chiều rộng render thường lớn hơn vì dấu và cụm từ. Test bằng screenshot Latin rồi ship VI = đoán mò.

Frontend hay đếm string.length trong JS (UTF-16 code unit). Với tiếng Việt cơ bản (NFC), hầu hết chữ có dấu là 1 code point — vẫn ổn hơn emoji. Vấn đề chính của mock UI không phải length API, mà là độ rộng glyph + wrap policy.

---

Quy trình mock đúng cho team Việt / outsourcing

Giai đoạn 1 — Lấp khối bằng Lorem

1. Mở công cụ tạo Lorem Ipsum
2. Đặt ví dụ 3 đoạn × 5 câu cho body landing, hoặc 1 đoạn × 2 câu cho card description
3. Copy vào Figma / HTML
4. Gắn nhãn rõ: placeholder — chưa phải copy cuối

Công cụ chạy trên trình duyệt, không cần tài khoản — phù hợp freelancer gửi mock nhanh cho client nước ngoài rồi localize VI sau.

Giai đoạn 2 — Fixture tiếng Việt bắt buộc trước approve

Giữ file fixture cạnh Storybook hoặc checklist QA:

title_short:  "Sữa"
title_median: "Sữa tươi hữu cơ 1L"
title_long:   "Gói đăng ký doanh nghiệp không giới hạn người dùng"
title_accent: "Ưu đãi đặc biệt tháng này — giảm ngay"
user_long:   "Nguyễn Thị Hồng Nhung Phương Anh"
btn_short:    "Mua"
btn_long:     "Tiếp tục thanh toán"
badge_long:   "Đang chờ xác nhận thanh toán"
empty:        ""
legal_long:   "Bằng việc tiếp tục, bạn đồng ý với Điều khoản sử dụng và Chính sách bảo mật của chúng tôi."

Render mỗi component với short / median / long / empty. Chỉ test median = vẫn đang đoán.

Giai đoạn 3 — Quy tắc truncate viết rõ

Trước handoff, chốt:

• Line clamp bao nhiêu dòng (1 / 2 / 3)?
• Tràn thì ellipsis + tooltip, wrap, hay clip cứng?
• Nút: cho phép 2 dòng trên mobile hay luôn một dòng + thu chữ?

Không ghi = mỗi designer/dev tự “vá” khác nhau trên từng màn.

---

Component vỡ sớm nhất khi đổi sang tiếng Việt

Surface	Vì sao dễ vỡ	Cách test
Button / chip	Động từ VI dài hơn “OK / Buy”	btn_long trên mobile 320px
Card title + price	Title dài đẩy giá xuống hàng	title_long + giá 1.299.000₫
Badge / toast	Phải hiện đủ trạng thái, không 2 từ Latin	badge_long, error đầy đủ
Breadcrumb	Tên section biên tập, không phải Home/Cat/Item	3 cấp tiêu đề VI dài
Form label + helper	Cột hẹp mobile, 2 dòng label + hint	Helper pháp lý dài
Avatar + tên	Họ tên Việt 4–5 tiếng	user_long cạnh avatar 32px

Nếu Storybook chỉ mount "Title" / "Description" bằng Latin, bug overflow sẽ tốt nghiệp từ design sang screenshot production.

---

Case study ngắn

Case 1: Freelancer — landing cho client Việt, mock bằng Lorem

Tình huống: Designer dùng 3 đoạn Lorem cho hero + feature cards. Client approve. Copywriter gửi headline một câu + mô tả pháp lý dài ở footer.

Hậu quả: Hero trống trải; footer đẩy CTA lên trên fold trên mobile.

Cách tránh: Sau Lorem, thêm pass “quá ít nội dung” (headline 1 từ) và “legal dài”. Lorem chỉ chứng minh texture — không chứng minh launch copy.

Case 2: Outsourcing team — app EN approve, bản VI giao sau

Tình huống: PM nước ngoài approve UI English. Sprint localize VI: mọi card dùng line-clamp: 2 calibrated trên EN.

Hậu quả: Tên SKU tiếng Việt bị cắt giữa cụm; support nhận ticket “thiếu chữ”.

Cách tránh: Definition of done gồm screenshot VI với fixture long. Không coi “EN pixel-perfect” là xong localization.

Case 3: Dev — đếm ký tự thay vì đo layout

Tình huống: Spec “title max 40 ký tự”. Copy VI 38 ký tự nhưng rộng hơn EN 50 ký tự vì font.

Cách tránh: Giới hạn UX nên là chiều rộng / số dòng, không chỉ length. Dùng fixture visual, không chỉ validator độ dài chuỗi.

---

Checklist trước khi gọi mock “xong”

---

Cách tạo Lorem trên Kawa Dev Tools

1. Mở Tạo văn bản mẫu Lorem Ipsum
2. Chọn số đoạn văn (1–20) và số câu mỗi đoạn (1–20)
3. Bấm Tạo văn bản → Sao chép
4. Dán vào Figma, Notion spec hoặc file HTML mock
5. Đổi sang fixture tiếng Việt ở bảng trên trước khi gửi approve cuối

Không cần đăng ký; xử lý trên trình duyệt — phù hợp khi chỉ cần vài đoạn filler trong 30 giây.

Kết hợp hữu ích:

• Đếm độ dài chuỗi / UTF khi so copy: Đếm ký tự
• Ảnh giữ chỗ song song với text: Dummy image nếu team đang dùng

---

Câu hỏi thường gặp (bổ sung)

Có nên bỏ hẳn Lorem Ipsum không?
Không. Dùng sớm để tốc độ. Thay trước khi approve UI hướng người dùng Việt.

Dummy tiếng Việt “vãn” (Trăm năm trong cõi…) có hơn Lorem không?
Hơn về script và dấu, nhưng vẫn cần worst-case có chủ đích — văn học cổ không cover nhãn nút và SKU dài.

Generator AI tạo copy giả có đủ không?
Tốt cho volume. Vẫn nên seed tay các chuỗi worst-case để generator không “làm trung bình hóa” mất bug overflow.

---

Tóm tắt

• Lorem Ipsum = dummy Latin để kiểm tra mật độ layout, không phải bằng chứng localization
• Tiếng Việt khác Latin về độ dài cụm từ, dấu thanh và nhãn UI — đó là lý do mock “đẹp” vẫn vỡ khi gắn copy thật
• Quy trình: tạo nhanh bằng Lorem Ipsum Kawa → mock → fixture VI short/long → chốt truncate → mới approve
• Component ưu tiên test: nút, card title, badge, toast, breadcrumb, form helper

Quy tắc cuối: Approve dựa trên Latin gọn là cách lên lịch bug layout cho tuần sau launch. Dummy text có chỗ đứng — miễn là bạn biết nó không thay được tiếng Việt thật.

---

Bài liên quan